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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The present document specifies the procedures used at the radio interface (Reference Point Um, see 3GPP TS 24.002) 
for the General Packet Radio Service (GPRS) Medium Access Control /Radio Link Control (MAC/RLC) layer within 
the digital cellular telecommunications system (Phase 2+). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

1.1 General 

This document specifies procedures for the following layers of the radio interface (Um reference point), the interface 
between the GSM/EDGE Radio Access Network (GERAN) and the Mobile Station (MS): 

- Radio Link Control (RLC) 

Medium Access Control (MAC), including Physical Link Control functions 
The procedures apply in A/Gb mode and may also apply in lu mode (see 3GPP TS 44.160). 

1 .2 Related documents 

The following documents provide information related to this document: 

3GPP TS 43.064 contains an overview of the GPRS radio interface (Um reference point). 

3GPP TS 44.003 specifies channel types, access capabilities and channel configurations at the Um reference 
point. 

3GPP TS 44.004 specifies services offered by the physical layer of the Um reference point. It also specifies 
control channels. RLC and MAC use these services and control channels. 

3GPP TS 24.007 specifies, in general terms, this protocol's structured functions, its procedures and its 
relationship with other layers and entities. It also specifies the basic message format and error handling applied 
by layer 3 protocols. 

3GPP TS 44.018 specifies GPRS procedures when operating on the Common Control Channel (CCCH) or on 
dedicated channels. 

- 3GPP TS 44.064 specifies the Logical Link Control (LLC) layer. 

- 3GPP TS 43.05 1 is an overall description of the GSM/EDGE Radio Access Network (GERAN) in lu mode. 

- 3GPP TS 44. 160 specifies RLC/MAC procedures specific to lu mode. 
3GPP TS 51.010 specifies test procedures for radio-interface signalling. 

1 .3 Use of logical control channels 

3GPP TS 45.002 defines three similar sets of logical control. 
The first set consists of the following logical control channels: 

Broadcast Control Channel (BCCH): downlink only, used to broadcast Cell specific information; 

Paging Channel (PCH): downlink only, used to send page requests to Mobile Stations (MSs); 

Random Access Channel (RACH): uplink only, used to request GPRS resources or a Dedicated Control 
Channel; 

Access Grant Channel (AGCH): downlink only, used to allocate GPRS resources or a Dedicated Control 
Channel; 

The second set consists of the following logical control channels (Packet Control Channels): 

Packet Broadcast Control Channel (PBCCH): downlink only, used to broadcast Cell specific information; 

Packet Paging Channel (PPCH): downlink only, used to send page requests to Mobile Stations (MSs); 
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Packet Random Access Channel (PRACH): uplink only, used to request GPRS resources; 

Packet Access Grant Channel (PAGCH): downlink only, used to allocate GPRS resources; 

Packet Associated Control Channel (PACCH): bi-directional, associated with a Temporary Block Flow (TBF); 

Packet Timing advance control channel uplink (PTCCH/U): used to transmit random access bursts to allow 
estimation of the timing advance for one MS in transfer state; 

Packet Timing advance control channel downlink (PTCCH/D): used to transmit timing advance updates for 
several MS. One PTCCH/D is paired with several PTCCH/U's. 

MBMS Packet Random Access Channel (MPRACH): uplink only, used during the initial counting procedure for 
MBMS. 

The third set consists of the following logical control channels (COMPACT control channels): 

- COMPACT Packet Broadcast Control Channel (CPBCCH): downlink only, used to broadcast Cell specific 
information; This channel broadcasts the same information as the PBCCH, but has a different physical structure 
(see 3GPP TS 45.002); 

COMPACT Packet Paging Channel (CPPCH): downlink only, used to send page requests to Mobile Stations 
(MSs) on a COMPACT control channel;; 

COMPACT Packet Random Access Channel (CPRACH): uplink only, used to request GPRS resources on a 
COMPACT control channel; 

- COMPACT Packet Access Grant Channel (CPAGCH): downlink only, used to allocate GPRS resources on a 
COMPACT control channel; 

Packet Associated Control Channel (PACCH): see above; 

Packet Timing advance control channel uplink (PTCCH/U): see above; 

Packet Timing advance control channel downlink (PTCCH/D): see above. 

1 .4 Use of logical traffic channels 

3GPP TS 45.002 defines the following logical traffic channels used by RLC and MAC: 

Traffic Channel (TCH): bidirectional, carries encoded speech or user data using GMSK on a dedicated basic 
physical subchannel (DBPSCH). TCH can be full-rate (TCH/F) or half-rate (TCH/H). 

Octal Traffic Channel (O-TCH): bidirectional, carries encoded speech using 8-PSK on a DBPSCH. O-TCH can 
be full-rate (O-TCH/F) or half-rate (O-TCH/H). 

Enhanced Traffic Channel (E-TCH): bidirectional, carries user data using 8-PSK on a DBPSCH. 

Packet Data Traffic Channel (PDTCH): downlink or uplink, carries user data using GMSK or 8-PSK on a shared 
basic physical subchannel (SBPSCH) or a DBPSCH. PDTCHs can be full-rate (PDTCH/F) or half-rate 
(PDTCH/H). 

1.5 Conventions 

Unless explicitly stated otherwise, the following conventions apply: 

The notations "further study", "FS" or "FFS" indicate the annotated text is not normative. 

- "GPRS " refers to "GPRS and EGPRS " . 

- "PBCCH" refers to "PBCCH and CPBCCH" . 

- "PPCH" refers to "PPCH and CPPCH". 

- "PRACH" refers to "PRACH and CPRACH". 
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- "PAGCH" refers to "PAGCH and CPAGCH". 

- References to "PDCH" also apply to "SBPSCH" and vice-versa. 

- "MBMS Assignment" refers to either "MBMS ASSIGNMENT (NON-DISTRIBUTION)" or "MBMS 
ASSIGNMENT (DISTRIBUTION)". 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 22.060: "General Packet Radio Service (GPRS); Service Description; Stage 1". 

[3] 3GPP TS 23.003: "Numbering, addressing and identification". 

[4] 3GPP TS 43.013: "Discontinuous Reception (DRX) in the GSM system". 

[5] 3GPP TS 43.064: " Overall description of GPRS radio interface; Stage 2". 

[6] 3GPP TS 24.002: "GSM - UMTS Public Land Mobile Network (PLMN) access reference 

configuration". 

[7] 3GPP TS 44.003: "Mobile Station - Base Station System (MS-BSS) interface; Channel structures 

and access capabilities". 

[8] 3GPP TS 44.004: "Layer 1 ; General requirements". 

[9] 3GPP TS 44.005: "Data Link (DL) layer; General aspects". 

[10] 3GPP TS 24.007: "Mobile radio interface signalling layer 3; General aspects". 

[II] 3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control Protocol". 

[12] 3GPP TS 44.064: " Mobile Station - Serving GPRS Support Node (MS-SGSN) Logical Link 

Control (LLC) Layer Specification 

[13] 3GPP TS 45.002: "Multiplexing and multiple access on the radio path". 

[14] 3GPP TS 45.003: "Channel coding". 

[15] 3GPP TS 45.008: "Radio subsystem Hnk control". 

[16] 3GPP TS 45.010: "Radio subsystem synchronization". 

[17] (void) 

[18] (void). 

[19] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service Description; Stage 2". 

[20] 3GPP TS 25.33 1 : "Radio Resource Control (RRC) protocol specification". 

[21] 3GPP TS 25.133: "Requirements for support of radio resource management (FDD)". 
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[22] 3GPP TS 25.123: "Requirements for support of radio resource management (TDD)". 

[23] ITU-T Recommendation T.4: "Standardization of Group 3 facsimile terminals for document 

transmission". 

[24] 3GPP TS 22.01 1: "Service accessibility". 

[25] 3GPP TS 25.101: "UE Radio Transmission and Reception (FDD)". 

[26] 3GPP TS 25.102: "UTRA (UE) TDD; Radio transmission and reception". 

[27] 3GPP TS 25.213: "Spreading and modulation (FDD)". 

[28] 3GPP TS 25.223: "Spreading and modulation (TDD)". 

[29] 3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected 

Mode". 

[30] 3GPP TS 45.005: "Radio transmission and reception". 

[31] 3GPP TS 45.009: "Link adaptation". 

[32] T1A/E1A-1S-2000-5-A: "CDMA 2000 Series". 

[33] 3GPP TS 51.010-1 (Rel-6): "Mobile Station (MS) conformance specification; Part 1: Conformance 

specification ". 

[34] 3GPP TS 5 1 .010-2 (Rel-6): "Mobile Station (MS) conformance specification; Part 2: Protocol 

Implementation Conformance Statement (ICS); proforma specification". 

[35] 3GPP TS 5 1 .010-3 (Rel-6): "Mobile Station (MS) conformance specification; Part 3: Layer 3 

Abstract Test Suite (ATS)". 

[36] 3GPP TS 5 1 .010-4 (Rel-6): "Mobile Station (MS) conformance specification; Part 4: SIM 

application toolkit conformance specification". 

[37] 3GPP TS 51.021: "Base Station System (BSS) equipment specification; Radio aspects". 

[38] 3GPP TS 43.05 1 : "GSM/EDGE Radio Access Network (GERAN); Overall Description - Stage 2" 

[39] 3GPP TS 44.160: "Mobile Station (MS) - Base Station System (BSS) interface; Radio Link 

Control/ Medium Access Control (RLC/MAC) protocol in lu mode" 

[40] Michel MOULY, "CSN. 1 Specification, Version 2.0", Cell & Sys, ISBN: 2-9510062-0-9. 

Web: http://perso.wanadoo.fr/cell.svs/ . 

[41] 3GPP TS 25.224: "Physical Layer Procedures (TDD)". 



3 Definitions, abbreviations and symbols 

3.1 Definitions 

This document uses the following definitions: 

A/Gb mode: mode of operation of the MS when connected to the Core Network via GERAN and the A and/or Gb 
interfaces. 

Block period: block period is the sequence of four timeslots on a PDCH used to convey one radio block 

Broadcast/multicast receive mode: In broadcast/multicast receive mode, the mobile station is receiving upper layer 
PDUs on packet data physical channels used for point- to -multipoint transmission (see sub-clause 5.3.1); it is not 
allocated any additional radio resource on packet data physical channels. Broadcast/multicast receive mode is a sub- 
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state of packet idle mode. The mobile station listens to the PBCCH and PCCCH or, if those are not provided by the 
network, to the BCCH and CCCH. 

Cell Change Notification (CCN): See sub-clause 5.5.1.1a. 

Dual transfer mode: In dual transfer mode, the mobile station is allocated radio resources providing an RR connection 
(3GPP TS 44.018) and one or more Temporary Block Flows on one or more packet data physical channels. The 
allocation of radio resource for the RR connection and the Temporary Block Flow(s) is co-ordinated by the network in 
agreement with the capabilities of the mobile station in dual transfer mode. 

EGPRS: Enhanced GPRS enables higher data rates through usage of 8PSK modulation in addition to OMSK. EGPRS 
also enables Incremental Redundancy operation. 

EGPRS TBF mode: refers to a TBF utilising the EGPRS enhancements, e.g. Incremental Redundancy and possibly 8- 
PSK. 

EGPRS TBF: a TBF running in EGPRS TBF mode. 

EGPRS-GMSK only TBF mode: refers to a TBF in EGPRS TBF mode but making only use of MCS-1 to MCS-4 
modulation and coding schemes. The number of PDCHs allocated to an EGPRS-GMSK only TBF can be extended to 
the maximum number of timeslots compatible with the GPRS multislot class of the MS. This mode is determined by the 
mobile station based on the aggregate timeslot allocation assigned by the network. In the case the aggregate timeslot 
allocation is not within the indicated EGPRS multislot class, but is within the indicated GPRS multislot class, a mobile 
station supporting this mode shall consider the TBF to be in EGPRS-GMSK only mode (see sub-clause 9.1.9.2). This 
mode is only applicable in packet transfer mode. 

Extended uplink TBF mode: In the extended uplink TBF mode, the uplink TBF may be maintained during temporary 
inactive periods, where the mobile station has no RLC information to send. The network determines the release of the 
uplink TBF (see sub-clause 9.3.1b). 

MS multislot class: refers to GPRS multislot class in case of a GPRS TBF mode or EGPRS-GMSK only TBF mode. In 
case of EGPRS TBF mode, MS multislot class refers to EGPRS multislot class. 

GPRS multislot class / EGPRS multislot class: refers to the different mobile station capabilities to transmit and 
receive on different combinations of multiple PDCHs. The multislot classes are defined in 3GPP TS 45.002. Note that 
the mobile station may indicate different multislot classes for circuit mode services for GPRS and for EGPRS (see 
3GPP TS 24.008). Different multislot class mobile stations are capable of supporting different medium access modes 
(see sub-clause 5.2.4). 

GPRS TBF mode: a TBF not utilising EGPRS enhancements. 

IR: Incremental redundancy, enables higher data rates through combining information from different transmissions of 
RLC data blocks when decoding. Also known as Hybrid Type Willi ARQ. 

lu mode: mode of operation of the MS when connected to the Core Network via GERAN or UTRAN and the lu 
interface. 

MAC-dedicated state: a MAC-control-entity state where a DBPSCH is assigned and no SBPSCH is assigned. This 
state only applies in lu mode. 

MAC-DTM state: a MAC-control-entity state where at least one DBPSCH and one SBPSCH are assigned. This state 
only applies in lu mode. 

MAC-idle state: a MAC-control-entity state where no basic physical subchannels are assigned. This state only applies 
in lu mode. 

MAC-shared state: a MAC-control-entity state where at least one SBPSCH is assigned. This state only applies in lu 
mode. 

MCS: Modulation and Coding Scheme. 

Multiple TBF procedures: A mobile station that supports multiple TBF procedures can support one or more 
concurrent TBFs in either direction while in packet transfer mode (A/Gb mode). A network that supports multiple TBF 
procedures can support one or more concurrent TBFs in either direction for a mobile station that supports multiple TBF 
procedures in packet transfer mode (A/Gb mode). 
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Non-extended uplink TBF mode: Where a distinction is needed, an uplink TBF, not operating in the extended uplink 
TBF mode, is referred as operating in the non-extended uplink TBF mode. 

Non-synchronized PS handover: The basic type of PS handover which is used when the time bases of the involved 
cells bear no particular relationship between themselves and when the MS cannot predict the timing advance to be used 
in the target cell before access in this cell. The requirements that apply for the non-synchronized PS handover are given 
in 3GPP TS 45.010. 

Packet access failure: Packet access failure refers to the access cases where the mobile is explicitly denied access to 
the network, i.e. receives a PACKET QUEUING NOTIFICATION message or a PACKET ACCESS REJECT 

message. 

Packet flow context: Packet Flow Context (PFC) procedures are described in 3GPP TS 23.060. A Packet Flow 
Identifier (PFI) is used to identify a PFC. 

Packet idle mode: In packet idle mode, the mobile station is prepared to transfer LLC PDUs on packet data physical 
channels (see sub-clause 5.3). The mobile station is not allocated any radio resource on a packet data physical channel; 
it listens to the PBCCH and PCCCH or, if those are not provided by the network, to the BCCH and the CCCH. 

Packet transfer mode: In packet transfer mode, the mobile station is prepared to transfer LLC PDUs on packet data 
physical channels (see sub-clause 5.4). The mobile station is allocated radio resource on one or more packet data 
physical channels for the transfer of LLC PDUs. 

Pre-synchronized PS handover: A type of PS handover where the MS uses the timing advance included in the PS 
HANDOVER COMMAND message for immediate use in the target cell. The requirements that apply for the pre- 
synchronized PS handover are given in 3GPP TS 45.010 

PS handover: PS handover is a feature used by the network to command a mobile station to move from its old (source) 
cell to a new (target) cell while operating in packet transfer mode and continue the operation of one or more of its 
ongoing packet switched services in the new cell using TBF resource allocations provided within a PS HANDOVER 
COMMAND message. 

Radio block: A radio block is the sequence of four normal bursts carrying one RLC/MAC protocol data units (see 
3GPP TS 44.004). (The one exception is a radio block occasionally used on PACCH consisting of a sequence of four 
access bursts, each carrying a repetition of one short RLC/MAC block.) 

Random access failure: Random access failure refers to the access case when the mobile station does not get any 
response from the network to its (EGPRS) PACKET CHANNEL REQUEST messages. 

Random values: In a number of places in this Technical Specification, it is mentioned that some value must take a 
"random" value, in a given range, or more generally with some statistical distribution. For such random values refer to 
3GPPTS 44.018. 

RLC/MAC block: A RLC/MAC block is the protocol data unit exchanged between RLC/MAC entities (see clause 10 
and 3GPP TS 44.004). 

RLC/MAC control block: A RLC/MAC control block is the part of an RLC/MAC block carrying a control message 
between RLC/MAC entities (see sub-clause 10.3). 

RLC data block: A RLC data block is the part of a RLC/MAC block carrying user data or signalling data received 
from an upper layer (see sub-clause 10.2). 

RLC Non-Persistent Mode: A mode of RLC operation where retransmissions are possible but it is not required that all 
RLC data blocks are correctly received at the receiving RLC endpoint. 

RR connection: An RR connection is a physical connection established between a mobile station and the network to 
support the upper layers' exchange of information flows. An RR connection is maintained and released by the two peer 
entities. 

RRC connection: An RRC connection is a point-to-point, bi-directional, logical connection between RRC peer entities 
in the mobile station and the GERAN characterised by the allocation of a G-RNTI. A mobile station has either zero or 
one RRC connections. RRC connections only apply in lu mode. 

Source BSS: Within the context of a PS handover the source BSS is the BSS controlling the cell in which the mobile 
station is camping prior to performing PS handover (i.e. it controls the old cell). 
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Synchronized PS handover: A type of PS handover which is possible when the time bases of the involved cells are 
synchronized, and for which no timing advance needs to be provided to the MS. The requirements that apply for the 
synchronized PS handover are given in 3GPP TS 45.010. 

Target BSS: Within the context of a PS handover the target BSS is the BSS controlling the cell in which the mobile 
station is camping after successful completion of PS handover (i.e. it controls the new cell). If the same BSS controls 
both the old cell and the new cell associated with the PS handover of any given mobile station then the source BSS and 
the target BSS are the same. 

TBF abort: The term "abort" as applied to TBF is used when the TBF is abruptly stopped without using the Release of 
TBF procedures defined in clause 9. 

TBF release: The term "release" as applied to TBF is used when the TBF is stopped using one of the Release of TBF 
procedures defined in clause 9. 

Temporary Block Flow (TBF): A Temporary Block Flow is, in A/Gb mode, a physical connection used by the two RR 
peer entities to support the unidirectional transfer of LLC PDUs on packet data physical channels (see sub-clause 5.2.1). 
In lu mode, a TBF is a logical connection offered by two MAC entities to support the unidirectional transfer of RLC 
PDUs on basic physical subchannels. 

Timer Expiry: A started timer has run the time specified. 

Timer Restart: A timer that may already be running is stopped and then started again to run the time specified. 

Timer Start: A timer is started to run the time specified. 

Timer Stop: A started timer is stopped and its value is then undefined. 

Uplink control timeslot: refers to the timeslot number of the timeslot where the PACCH/U for the MS is located. This 
parameter is set to the value of the Uplink Control timeslot IE in an assignment message. Otherwise, this parameter is 
unassigned 

Uplink State Flag (USF): The Uplink State Flag (USF) is used on PDCH channel(s) to allow multiplexing of uplink 
Radio blocks from different TBFs belonging to the same or different mobile stations (see sub-clause 5.2.3, clause 10 
and 3GPP TS 45.002). 

Upper-layer PDU: An upper-layer PDU is, in A/Gb mode, an LLC PDU and, in lu mode, an RRC message, a PDCP 
PDU or a PDU from the NAS user plane. 

3.2 Abbreviations 

This document uses abbreviations from 3GPP TR 21.905 and 3GPP TS 43.064. It also uses the following abbreviations: 

ARI Access Request Identifier 

ARQ Automatic Repeat reQuest 

AS Access Stratum 

BCCH Broadcast Control CHannel 

BSS Base Station Subsystem 

CBCH Cell Broadcast CHannel 

CC Call Control 

CCCCH Compact CCCH 

CCCH Common Control CHannel 

CCN Cell Change Notification 

CN Core Network 

CPBCCH Compact PBCCH 

CS-/ GPRS Coding Scheme ; 

DC Dedicated Control 

DLC Data Link Control 

DBPSCH Dedicated Basic Physical Sub CHannel 

ECSD Enhanced Circuit Switched Data 

EDGE Enhanced Data rates for Global Evolution 

E-FACCH Enhanced FACCH 

EGPRS Enhanced General Packet Radio Service 
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E-TCH Enhanced TCH 

FACCH Fast Associated Control CHannel 

GC General Control 

GERAN Gsm/Edge Radio Access Network 

GPRS General Packet Radio Service 

GRA Geran Registration Area 

G-RNTI Geran Radio Network Temporary Identity 

GSM Global System for Mobile communications 

IETF Internet Engineering Task Force 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

LCS Location Services 

LLC Logical Link Control 

MAC Medium Access Control 

MCS-i EGPRS Modulation and Coding Scheme / 

MM Mobility Management 

MPRACH MBMS Packet Random Access Channel 

MS Mobile Station 

NAS Non Access Stratum 

NSAPI Network-layer SAPI 

Nt Notification 

O-FACCH Octal FACCH 

O-TCH Octal TCH 

PBCCH Packet BCCH 

PDCH Packet Data CHannel 

PDCP Packet Data Convergence Protocol 

PDP Packet Data Protocol 

PDTCH Packet Data TCH 

PDU Protocol Data Unit 

PFC Packet Flow Context 

PFI Packet Flow Identifier 

PLMN Public Land Mobile Network 

PTCCH Packet Timing-advance Control CHannel 

p-t-m point- to -multipoint 

P-TMSI Packet TMSI 

QoS Quality of Service 

RAB Radio Access Bearer 

RANAP Radio Access Network Application Part 

RB Radio Bearer 

RLC Radio Link Control 

RNC Radio Network Controller 

RNS Radio Network Subsystem 

RNSAP Radio Network Subsystem Application Part 

ROHC Robust Header Compression 

RR Radio Resource 

RRC Radio Resource Control 

RTP Real Time Protocol 

SACCH Slow Associated Control CHannel 

SAP Service Access Point 

SAPI Service Access Point Identifier 

SDCCH Stand-alone Dedicated Control CHannel 

SDU Service Data Unit 

SBPSCH Shared Basic Physical Sub CHannel 

TBF Temporary Block Flow 

TCH Traffic Channel 

TCP Transmission Control Protocol 

TLLI Temporary Logical Link Identifier 

TMSI Temporary Mobile Subscriber Identity 

UDP User Datagram Protocol 

UMTS Universal Mobile Telecommunication System 

USF Uphnk State Flag 

UTRAN UMTS Terrestrial Radio Access Network 
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3.3 Symbols 

This document uses the following symbols: 

A Interface between a BSS and a 2G MSC 

Gb Interface between a BSS and a 2G SGSN 

lu Interface between a BSS or an RNC and a 3G MSC or a 3G SGSN 

lu-cs Interface between a BSS or an RNC and a 3G MSC 

lu-ps Interface between a BSS or an RNC and a 3G SGSN 

lur-g Interface between two BSSs or between a BSS and an RNC 

Um Interface between an MS and the GERAN 

4 Layered overview of radio interface 

The Radio Resource sublayer provides the functions necessary for: 

Radio Resource (RR) management of packet data physical channels (PDCHs); and 

Radio Link Control and Medium Access Control (RLC/MAC) on packet data physical channels. 

As shown in figure 4.1, the RR sublayer provides services to the MM and LLC sublayers. The RR sublayer utilises the 
services of the Data Link layer (signalling layer 2) and the Physical Link layer. The packet logical channels PBCCH, 
PCCCH (including PPCH, PAGCH and PRACH), PACCH and PDTCH, are multiplexed onto the packet data physical 
channels on a per radio block basis. 
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MM sublayer 




Data Link layer (signalling layer 2) 



PDCH 



Physical Link layer 



Figure 4.1 : Protocol architecture of Radio Resource (RR) sublayer and RLC/MAC function 



4.1 Layer services 



The RR sublayer provides services for the transfer of upper layer PDUs using a shared medium between multiple 
mobile stations and the network. Direct communication is only possible between the network and one or more mobile 
stations. The RLC/MAC function supports three modes of operation: 

unacknowledged operation; 

acknowledged operation; and 

non-persistent operation. 

The RR sublayer further provides services for the paging of mobile stations. 



4.2 Layer functions 



The RLC function defines the procedures for segmentation and reassemble of LLC PDUs into RLC/MAC blocks and, 
in RLC acknowledged mode of operation, for the Backward Error Correction (BEC) procedures enabling the selective 
retransmission of unsuccessfully delivered RLC/MAC blocks. In RLC acknowledged mode of operation, the RLC 
function preserves the order of higher layer PDUs provided to it. 

The RLC function provides also link adaptation. 

In EGPRS in RLC acknowledged mode of operation, the RLC function may provide Incremental Redundancy (IR). 
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The MAC function defines the procedures that enable multiple mobile stations to share a common transmission 
medium, which may consist of several physical channels. The function may allow a mobile station to use several 
physical channels in parallel, i.e. use several timeslots within the TDMA frame. 

For the mobile station originating access, the MAC function provides the procedures, including the contention 
resolution procedures, for the arbitration between multiple mobile stations simultaneously attempting to access the 
shared transmission medium. 

For the mobile station terminating access, the MAC function provides the procedures for queuing and scheduling of 

access attempts. 

When the PS handover procedure is supported the RLC and MAC functions provide the procedures for directing a 
mobile station to a new cell and continuing packet switched services without the use of contention resolution procedures 
(i.e. RACH/PRACH) in the new cell. 



4.3 Service primitives 

Information flow between layers is performed by the use of Service Primitives. Service Access Points (SAP) and their 
corresponding Service Primitives for the RR sublayer are defined in 3GPP TS 24.007. 

4.4 Services required from lower layers 

The RLC/MAC function uses the services provided by the physical link layer as defined in 3GPP TS 44.004. 

The RR sublayer may use the services provided by the data link layer as defined in 3GPP TS 44.005. Moreover, the RR 
sublayer directly uses services provided by the physical layer such as BCCH searching, as defined in 3GPP TS 44.004. 

5 Introduction to the IVIedium Access Control (MAC) 

procedures 

5.1 General 

The Medium Access Control procedures include the functions related to the management of the shared transmission 
resources, e.g. the packet data physical channels and the radio link connections on packet data physical channels. 

The Medium Access Control procedures support the provision of Temporary Block Flows (TBFs) that allow the point- 
to-point transfer of signalling and user data within a cell between the network and a mobile station. The MAC 
procedures also support the provision of MBMS radio bearers that allow the point-to-multipoint transfer of signalling 
and user data within a cell between the network and one (or more) mobile station(s). 

Moreover, the Medium Access Control procedures include the procedures for reception of PBCCH and PCCCH, which 
permits autonomous cell reselection performed by the mobile station (see 3GPP TS 45.008). 

5.2 Multiplexing principles 
5.2.1 Temporary Block Flow 

A Temporary Block Flow (TBF) is a physical connection used by the two RR entities to support the unidirectional 
transfer of upper layer PDUs on packet data physical channels. 

The TBF is allocated radio resources on one or more PDCHs and comprises a number of RLC/MAC blocks carrying 
one or more upper layer PDUs. A TBF is temporary and is maintained only for the duration of the data transfer (i.e. 
until there are no more RLC/MAC blocks to be transmitted and, in RLC acknowledged mode, all of the transmitted 
RLC/MAC blocks have been successfully acknowledged by the receiving entity). 
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A TBF may operate in either GPRS or EGPRS TBF mode. The network sets the TBF mode in the 

PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK ASSIGNMENT, 

PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET TIMESLOT 

RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE, IMMEDIATE ASSIGNMENT or PACKET CS 

RELEASE INDICATION message. The EGPRS TBF mode is only supported by EGPRS capable MSs. 

If an MS is assigned concurrent TBFs, these shall be in the same TBF mode. 

For the case where a mobile station supports multiple TBF procedures the maximum number of TBFs it can support 
concurrently is not specified. Mobile station implementations are expected to ensure that the mobile station can support 
a sufficient number of TBFs to operate all the PDP contexts it has activated. As such, a mobile station may choose to 
release, modify or activate one or more PDP contexts when prioritizing the services it wants to operate concurrently. 
The network is not required to consider any potential complexity limitations regarding the number of concurrent TBFs 
when establishing an uplink or downlink TBF for a mobile station that supports multiple TBF procedures. 

The following messages are used only if both the MS and network support multiple TBF procedures: 

- MULTIPLE TBF UPLINK ASSIGNMENT 

- MULTIPLE TBF DOWNLINK ASSIGNMENT 

- MULTIPLE TBF TIMESLOT RECONFIGURE. 



5.2.2 Temporary Flow Identity 



Each TBF is assigned a Temporary Flow Identity (TFI) by the network. The mobile station shall assume that the TFI 
value is unique among concurrent TBFs in the same direction (uplink or downlink) on all PDCHs used for the TBF. The 
same TFI value may be used concurrently for TBFs on other PDCHs in the same direction and for TBFs in the opposite 
direction. 

An RLC/MAC block associated with a certain TBF shall comprise a TFI. The TBF is identified by the TFI together 
with, in case of a RLC data block, the direction (uplink or downlink) in which the RLC data block is sent; and in case of 
a RLC/MAC control message, the direction in which the RLC/MAC control message is sent and the message type. 

Global_TFI is used to unambiguously identify the mobile station in packet transfer mode, MAC-Shared state, dual 
transfer mode or MAC-DTM state within an uplink or downlink RLC/MAC control message. If present, the Global TFI 
addresses the MS using either an uplink TFI or downlink TFI of the MS. Which TFI is used is at the discretion of the 
sender except where explicitly defined by procedure. For the mobile station in broadcast/multicast receive mode, the 
Global TFI includes the MBMS Bearer Identity of the MBMS radio bearer the RLC/MAC control message relates to (in 
the most significant bit(s) of the DOWNLINK_TFI field) and, where explicitly defined by procedure, the current 
MS_ID of the mobile station the message relates to (in the remaining least significant bit(s) of the DOWNLINK_TFI 
field). 

5.2.3 Uplink State Flag 

An Uplink State Flag (USE) is included in the header of each RLC/MAC block on a downlink PDCH, as specified in 
clause 10. It may be used by the network to control the multiplexing of different mobile stations and TBFs on an uplink 
PDCH. The use of USE is further specified in 3GPP TS 45.002. 

5.2.4 Medium Access modes 

Three medium access modes are supported: 

Dynamic Allocation, characterised by that the mobile station detecting an assigned USE value for each assigned 
uplink PDCH and block or group of four blocks that it is allowed to transmit on that PDCH (see sub-clause 
8.1.1.1); 

Extended Dynamic Allocation characterised by the mobile station detecting an assigned USE value for any 
assigned uplink PDCH allowing the mobile station to transmit on that PDCH and all higher numbered assigned 
PDCHs in the same block or group of four blocks (see sub-clause 8.1.1.2); 
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Exclusive Allocation, characterised by the mobile station being granted the exclusive right to transmit on the 
assigned PDCH/H for the duration of an uplink TBF (see sub-clause 8.1.1.3a). Exclusive allocation is applicable 
only in dual transfer mode. When using exclusive allocation, only one TBF shall be established in the uplink. 

Dynamic Allocation medium access mode shall be supported by all networks that support GPRS. The support of 
Extended Dynamic Allocation is optional for the network. 

Dynamic Allocation shall be supported in all mobile stations. The support of Extended Dynamic Allocation is 
mandatory for mobile stations of multislot classes 22, 24, 25 and 27, and for multislot class type 1 mobile stations that 
can transmit on three or more timeslots (either PDCH or TCH). The support of Extended Dynamic Allocation for 
mobile stations of all other multislot classes is optional and shall be indicated in the MS Radio Access Capability. 

The exclusive allocation shall be used in dual transfer mode during uplink operation with a half -rate PDCH. 

The network shall ensure that the medium access mode and the resource allocation used for a mobile station is 
compatible with the multislot class of the mobile station (the MS classes of multislot capability are defined in 
3GPP TS 45.002). 

NOTE: Different multislot classes may apply for a certain mobile station in packet transfer mode and in dual 
transfer mode, respectively. 

5.2.4a Multiplexing of GPRS and EGPRS TBF mode capable mobile stations 

GPRS and EGPRS TBF mode capable mobile stations can be multiplexed dynamically on the same PDCH. 

If dynamic or extended dynamic allocation is used, a mobile station in GPRS TBF mode or EGPRS-GMSK only TBF 
mode shall be able to detect the USE that assigns the uplink to that mobile station. The network shall use GMSK 
modulation, i.e. either CS-1 to CS-4 or MCS-1 to MCS-4, in those blocks. The other blocks may use 8PSK modulation. 
A mobile station in EGPRS TBF mode shall be able to detect the USE that assigns the uplink to that mobile station. The 
network may use either GMSK modulation or 8-PSK modulation, i.e. CS-1 to CS-4, MCS-1 to MCS-4 or MCS-5 to 
MCS-9 in those blocks. 

NOTE 1: The stealing bits in the EGPRS GMSK blocks are set to indicate CS-4. The coding and interleaving of the 
USF is done as defined for CS-4. That leads to: 

1) A GPRS mobile station is able to detect the USF in EGPRS GMSK blocks. The risk that the rest of 
the block will be misinterpreted as valid information is low. 

2) An EGPRS mobile station cannot differentiate CS-4 blocks from EGPRS GMSK blocks by decoding 
the stealing bits only. However, an EGPRS mobile station in EGPRS TBF mode needs only to decode 
GMSK blocks assuming either of MCS-1 to MCS-4, in order to determine if they were aimed for it. 

NOTE 2: Due to mobile station synchronisation reasons, special requirements apply for the scheduling, the 

modulation and coding scheme and the output power of blocks that are transmitted to a mobile station 
with an active uplink or downlink TBF, see 3GPP TS 45.008. 

5.3 Packet idle mode 

In packet idle mode no temporary block flow (TBF) exists. 

In packet idle mode, the mobile station monitors the relevant paging subchannels on PCCCH, if such is present in the 
cell. If a PCCCH is not present in the cell, the mobile station monitors the relevant paging subchannels on CCCH. 

In packet idle mode, upper layers may require the transfer of a upper layer PDU, which implicitly triggers the 
establishment of a TBF and the transition to packet transfer mode. 

In packet idle mode, upper layers may require the establishment of an RR connection. When the mobile station enters 
dedicated mode (see 3GPP TS 44.018), it may leave the packet idle mode, if the mobile station limitations make it 
unable to handle the RR connection and the procedures in packet idle mode simultaneously. 

In packet idle mode, if a mobile station starts listening to an MBMS radio bearer, it shall enter broadcast/multicast 
receive mode (see sub-clause 5.3.1). 
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5.3.1 Broadcast/multicast receive mode 

In broadcastymulticast receive mode, the mobile station listens to an MBMS radio bearer. 

Broadcast/multicast receive mode can only be entered by a mobile station when in packet idle mode; when leaving 
broadcast/multicast receive mode, the mobile station shall return to packet idle mode. 

Whenever a mobile station leaves broadcast/multicast receive mode to enter packet transfer mode, upon returning to 
packet idle mode it may re-enter broadcast/multicast receive mode to resume the reception of the ongoing MBMS 

session(s). 

The mobile station receives the system information and paging messages on the (P)BCCH and (P)CCCH as specified 
for packet idle mode or on the PACCH/D associated with the MBMS radio bearer, depending on the value of the 
MBMS In-band Signalling Indicator information element included in the MBMS ASSIGNMENT and MBMS 
NEIGHBOURING CELL INFORMATION messages. 

If the use of in-band signalling has been indicated (by the MBMS In-band Signalling Indicator), only mobile stations 
that have an MS_ID on the MBMS radio bearer shall be addressed with paging messages on the PACCH/D of that 
MBMS radio bearer. Mobile stations without an MS_ID shall continue monitoring their paging groups on the paging 
channel(s) on the (P)CCCH and skip the reception of the radio blocks of the MBMS radio bearer that prevent the 
monitoring of their paging groups, if needed. 

In this specification, requirements for mobile stations in packet idle mode apply also to mobile stations in 
broadcast/multicast receive mode unless stated otherwise. 

5.4 Packet transfer mode 

In packet transfer mode, the mobile station is allocated radio resources providing one or more TBFs for physical point- 
to-point connection(s) on one or more packet data physical channels for the unidirectional transfer of upper layer PDUs 
between the network and the mobile station. Successive transfer of one or more upper layer PDUs is possible. 
Concurrent TBFs may be established in opposite directions. The RR sublayer provides the following services: 

transfer of upper layer PDUs in RLC acknowledged mode; 

transfer of upper layer PDUs in RLC unacknowledged mode; 

transfer of upper layer PDUs in RLC non-persistent mode. 

When a transfer of upper layer PDUs terminates, in either downlink or uplink direction, the corresponding TBF is 
released. In packet transfer mode, when all TBFs have been released, in downlink and uplink direction, the mobile 
station returns to packet idle mode. 

In packet transfer mode, upper layers may require the establishment of an RR connection. When the mobile station 
enters dedicated mode (see 3GPP TS 44.018), it may abort all ongoing TBFs and leave the packet transfer mode, if the 
mobile station limitations make it unable to handle the RR connection and the procedures in packet transfer mode 
simultaneously. 

In packet transfer mode, a mobile station that supports PS handover may be ordered to move to a new cell through the 
use of a PS HANDOVER COMMAND message that provides resources to be used for one or more of its ongoing TBFs 
in the new cell (i.e. TBF resources in the new cell that have been pre-allocated by the target BSS). A mobile station 
indicates that it supports PS handover in the PS Handover Capability field in the MS Radio Access Capability IE (see 
3GPP TS 24.008). The network may initiate the PS handover procedure as a result of various trigger conditions as 
described in sub-clause 8. 10.3. L The PS handover procedure is described in sub-clause 8.10. 

5.4a Dual transfer mode 

In dual transfer mode, the mobile station is allocated radio resources providing an RR connection on a dedicated traffic 
channel and one or more TBFs on one or more packet data physical channels. The allocation of radio resources for the 
RR connection and the TBFs is co-ordinated by the network, in agreement with the capabilities of the mobile station in 
dual transfer mode. 
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If a mobile station that supports multiple TBF procedures has entered dual transfer mode where an uplink TBF is 
operating in exclusive allocation mode then no additional uplink TBFs may be requested. If exclusive allocation is not 
used a mobile station in dual transfer mode that supports multiple TBF procedures may request the establishment of one 
or more additional uplink TBFs by sending a PACKET RESOURCE REQUEST message on the PACCH. If this occurs 
and the network determines that re-allocation of the RR connection is required before it can satisfy the requested TBFs 
it sends the mobile station a DTM ASSIGNMENT COMMAND message to reallocate the RR connection and a 
combination of one or more ongoing uplink and downlink TBFs as specified in 3GPP TS 44.018. 

Successive transfer of one or more upper layer PDUs is possible. Concurrent TBFs may be established in opposite 
directions. Mobile stations supporting multiple TBF procedures may have multiple concurrent TBFs established in 
opposite directions. The transfer of upper layer PDUs in RLC acknowledged or RLC unacknowledged mode is 
provided. 

When a transfer of upper layer PDUs terminates, in either downlink or uplink direction, the corresponding TBF is 
released. In dual transfer mode, when all TBFs have been released, in downlink and uplink directions, the mobile 
station enters dedicated mode. 

In dual transfer mode, at the release of the RR connection, the mobile station may abort all ongoing TBFs and enter 
packet idle mode. If the mobile station and the network support enhanced DTM CS release procedure the mobile station 
may continue in packet transfer mode without entering packet idle mode, after the release of the RR connection. 

5.5 General procedures in packet idle and packet transfer 
modes 

Unless explicitly stated, the requirements in this sub-clause (and sub-clauses) apply only in packet idle mode and in 
packet transfer mode, neither in dedicated mode nor in dual transfer mode. 

5.5.1 IVIobile station side 

The mobile station in either packet idle or packet transfer modes shall monitor the system information broadcast in the 
cell. 

In packet idle mode, the mobile station shall monitor the radio blocks on PCCCH or CCCH, as defined in sub- 
clauses 5.5.1.5 and 5.5.1.6. The determination of the paging group for the mobile station is defined in 3GPP TS 45.002. 

5.5.1.1 Cell reselection 

Cell reselection in packet idle and packet transfer modes is specified in 3GPP TS 45.008. The RR entity on the mobile 
station side indicates to the upper layers the availability of a cell and a cell change when decided by the RR sublayer. 
Upper layers are advised of system information broadcast in the cell when a new cell has been selected, or when a 
relevant part of this information changes. 

When the mobile station reselects a new (target) cell, the support of GPRS in the target cell is indicated in system 
information sent on BCCH, see 3GPP TS 44.018. If the mobile station has received a PBCCH description for the target 
cell, it shall assume that GPRS is supported, without further receiving system information on BCCH. 

NOTE: A PBCCH description for the target cell may be received in the packet system information (neighbour 
cell information in PSI3 and 3bis) and/or in the MBMS NEIGHBOURING CELL INFORMATION 
message (for a mobile station in broadcast/multicast receive mode) in the old serving cell, or in a BCCH 
message (SI13) in the target cell. 

If a cell supports GPRS, the mobile station may perform packet access. If a cell does not support GPRS, the mobile 
station is not allowed to perform packet access. 

When a cell reselection is determined by the mobile station or ordered by the network, the mobile station may continue 
its operation in packet idle or in packet transfer mode in the old serving cell, while acquiring certain system information 
for the target cell. 

When a cell reselection is determined by the mobile station in broadcast/multicast receive mode, it shall leave the old 
serving cell immediately if the distribution of MBMS NEIGHBOURING CELL INFORMATION messages is not 
supported in the old serving cell (see sub-clause 7.7.3). If the distribution of MBMS NEIGHBOURING CELL 
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INFORMATION messages is supported in the old serving cell, the mobile station shall continue its operation in 
broadcast/multicast receive mode in the old serving cell as follows: 

if the mobile station has received for the target cell the MBMS bearer description for each session it is 
acquiring it shall leave the cell immediately after it receives an MBMS NEIGHBOURING CELL 
INFORMATION message for that target cell with the same MBMS_PTM_CHANGE_MARK as the last one 
received (see note), or after Is after cell reselection is determined, whichever occurs first; 

otherwise the mobile station shall leave the cell immediately after Is after cell reselection is determined 

NOTE 1: An MBMS_PTM_CHANGE_MARK is one received in an MBMS NEIGHBOURING CELL 
INFORMATION message for a session the mobile station is acquiring 

NOTE 2: The behaviour of the mobile station after leaving the old serving cell is described in sub-clause 8.1.6. 

If the old cell does not support CCN, the operation in the old cell shall be aborted when one of the following conditions 
are met: 

the mobile station starts to receive information on PBCCH in the target cell; 

the mobile station has received the SI13 message (see 3GPP TS 44.018) and there is no PBCCH present in the 
target cell; or 

the criteria for camping on the old cell are no longer fulfilled (see 3GPP TS 45.008). 

If PBCCH is present in the target cell, the mobile station shall delay the start of receiving information on PBCCH until 
the first occurrence of PSIl in block BO. If the reception of PSIl or PSI2 messages fails (see sub-clause 5.5.1.2) the 
mobile station may re-establish and continue its operation in the old cell, until the next occurrence of PSIl in block BO, 
unless the mobile station is in broadcast/multicast receive mode and performs fast reception resumption (see sub-clause 
8.1.6.2) of at least one MBMS session in the target cell. 

While the operation is maintained in the old cell, the mobile station may suspend its TBF(s) or suspend the monitoring 
of radio blocks on PCCCH and CCCH, in order to receive necessary information on BCCH in the target cell. Such 
suspension may be required in both packet idle and packet transfer modes, but shall not apply in broadcast/multicast 
receive mode. It is performed without notification to the network. 

Suspension of the operation in the old cell for this purpose is allowed during the time required, for each message and 
according to the mobile station's multislot class, to receive the required messages on BCCH in the target cell. The 
allowable suspension of an uplink TBF may be extended with one block period, in case of dynamic or extended 
dynamic allocation, if the mobile station is unable to receive the corresponding USE due to the suspension of downlink 
operation. 

When the conditions are fulfilled to switch to the new cell, the mobile station shall abort all TBFs in progress by 
immediately ceasing to decode the downlink, ceasing to transmit on the uplink, stopping all RLC/MAC timers except 
for timers related to measurement reporting. The mobile station shall then switch to the identified specified new cell and 
shall obey the relevant RLC/MAC procedures on this new cell. 

If the old cell supports CCN, a mobile station shall, when the cell reselection has been determined for other reason than 
path loss criterion parameter CI becomes negative, follow the procedures for Network Assisted Cell Change as 
specified in sub-clauses 5. 5. 1.1a. 2 and 8.8.2. 

If the old cell supports CCN, a mobile station may, when the cell reselection has been determined because the path loss 
criterion parameter CI has become negative, follow the procedures for Network Assisted Cell Change as specified in 
sub-clauses 5.5.1.1a.2 and 8.8.2. 

Under no circumstances and independent of whether CCN mode is supported, operations in the old cell shall be 
continued more than 5 s after a cell reselection has been determined. 

5.5.1.1a Network Assisted Cell Change 

The mobile station shall support the Network Assisted Cell Change procedures. The Network Assisted Cell Change 
consists of two independent procedures: 

One procedure that can assist a mobile station in packet transfer mode or MAC-Shared state with neighbour cell 
system information for a GSM neighbouring cell required for initial packet access after a cell change; 
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one procedure in which the mobile station notifies the network when it has determined to reselect to another 
GSM or to a 3G cell and delays the cell re-selection (CCN mode procedures) to let the network e.g. in the case of 
reselection to a GSM cell, respond with neighbour cell system information. 

The Network Assisted Cell Change procedures are part of the GERAN Feature Package 1. A mobile station indicating 
support of the GERAN Feature Package 1 in the Mobile Station Classmark 3 IE, the MS Radio Access Capability IE 
and the MS Radio Access Capability 2 IE supports the Network Assisted Cell Change procedures (see 
3GPP TS 24.008). 

5.5.1 .1a.1 Neighbour Cell System Information Distribution 

The network may send GSM neighbour cell system information to a mobile station in packet transfer mode or MAC- 
Shared state. A mobile station, which receives this information, shall store the information for 30 seconds and during 
that period the information can be used for initial access in the neighbour cell (see sub-clause 8.8.1). 

5.5.1. 1a.2 CCN Mode 

A mobile station, which has CCN Enabled, can enter CCN Mode. 

The mobile station shall enable CCN when the following criteria are fulfilled: 

the mobile station is camping on a cell (see 3GPP TS 45.008); and 

the network indicates CCN ACTIVE/3G CCN ACTIVE either in system information to all mobile stations in the 
cell or in an individual order to a certain mobile station; and 

the mobile station is neither in dedicated mode nor Dual Transfer Mode; and 

the mobile station is in NCO or in NCI mode; and 

the mobile station is in Packet Transfer mode. 

The CCN procedures and the criteria for entering and leaving CCN mode are specified in sub-clauses 8.8.2 and 8.8.3. 

5.5.1.1b Release of RR connection 
5.5.1. Ib.1 General 

After the release of an RR connection (see 3GPP TS 44.018, Normal release procedure and Abnormal cases), if the 
mobile station during the RR connection is unable to monitor the system information broadcast on BCCH or PBCCH 
(i.e. GPRS class B or GPRS class A mode of operation using DTM), the mobile station shall acquire the system 
information broadcast in the serving cell. The acquisition of system information shall be performed according to the 
requirements in sub-clause 5.5.1.2 (PBCCH present in the cell) or sub-clause 5.5.1.3 (PBCCH not present in the cell). 
The mobile station shall not attempt a packet access or accept a packet downlink assignment before those requirements 
are fulfilled. 

The following exceptions, stated in sub-clauses 5. 5. 1.1b. 2 to 5.5.1.1b.4, may apply. 

5.5.1 .1 b.2 Continuation of PBCCH information 

At the establishment of an RR connection and if PBCCH is present in the cell, the mobile station may keep the PSI 
messages received on PBCCH before the RR connection establishment. 

If the RR connection is established, maintained and released in the same serving cell and the MS has received PSI14 
messages or received and acted upon PSIl messages during dual transfer mode at least every 30 seconds such that 

- for PSIl, the value of the PBCCH_CHANGE_MARK has indicated no change in the PSI messages (see sub- 
clause 5.5.1.2.1), and 

for PSI14, all instances of the PSI14 messages indicate no change in the contents of PSI messages. 
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the mobile station may resume the supervision of PBCCH_CHANGE_MARK and update of PBCCH information, 
defined in sub-clause 5.5.1.2.1, and need not initiate a complete acquisition of PBCCH information, as specified in sub- 
clause 5.5.1.2. 

5. 5. 1.1b. 3 Continuation of BCCH information 

At the establishment of an RR connection and if PBCCH is not present in the cell, the mobile station may keep the SI 
messages received on BCCH before the RR connection establishment. 

If the RR connection is established, maintained and released in the same serving cell and the MS has received PSI14 
messages or received and acted upon PSI13/SI13 messages during dual transfer mode at least every 30 seconds such 
that the value of the BCCH_CHANGE_MARK has indicated no change in the SI messages (see sub-clause 5.5.1.3.1), 
the mobile station may resume the supervision of BCCH_CHANGE_MARK and update of BCCH information, defined 
in sub-clause 5.5.1.3.1, and need not initiate a complete acquisition of BCCH information, as specified in sub-clause 
5.5.1.3. 

5.5. 1 . 1 b.4 Receipt of PSI1 4 message in dual transfer mode 

In dual transfer mode, the mobile station may receive the PSI14 message on PACCH in the serving cell. If the RR 
connection is released in the same serving cell within 30 s after the PSI14 message was last received, the mobile station 
may use the PSI14 message as a substitute for the SI13 message after the release of the RR connection, until the SI13 
message has been received or the mobile station starts to receive information on PBCCH. 

The presence of a PBCCH in the cell is indicated by a PBCCH description in the PSI14 message. If the message does 
not contain the PBCCH description, the mobile station shall assume that PBCCH is not present in the cell. 

After the release of the RR connection and if PBCCH is present in the cell, the mobile station shall perform a complete 
acquisition of PBCCH information, as defined in sub-clause 5.5.1.2. 

After the release of the RR connection and if PBCCH is not present in the cell, the mobile station shall perform a 
complete acquisition of BCCH information, as defined in sub-clause 5.5.1.3. The mobile station shall attempt to receive 
the SI13 (or PSI13) message within 30 s after the last receipt of the PSI14 message. 

5.5.1 .1 b. 5 Acquisition of system information for enhanced DTM CS release procedure in 

dual transfer mode 

If the mobile station and the network support enhanced DTM CS release procedure, the network may delay the release 
of the RR connection until the mobile station has received the needed system information, in order to maintain the radio 
resources on the PDCH(s) after the release of the RR connection. 

The network initiates enhanced DTM CS release by sending the PACKET CS RELEASE INDICATION message on 
PACCH with the ENHANCED_DTM_CS_RELEASE_INDICATION parameter set to indicate that the RR connection 
is released and starts timer T3197. 

On receipt of PACKET CS RELEASE INDICATION message with the 

ENHANCED_DTM_CS_RELEASE_INDICATION parameter set to indicate that the RR connection is released, the 
mobile station shall send the PACKET SI STATUS (respectively PACKET PSI STATUS if the PBCCH is present) 
message on PACCH to indicate which system information messages were stored while in the dual transfer mode by the 
mobile station. The following system information (respectively packet system information) messages are required to 
maintain radio resources and enter packet transfer mode after the release of the RR connection: 

PSIl, PSI2 and PSI14 in the Received PSI Message List; or respectively 

SI13, SI3 and SIl, if present, in the Received SI Message List. 

The PSI (respectively SI) messages listed above shall be indicated as the first PSI (respectively SI) messages indicated 
in the PACKET PSI STATUS (respectively PACKET SI STATUS) messages. If other PSI (respectively SI) messages 
are indicated in the PACKET PSI STATUS (respectively PACKET SI STATUS) message, the priority order defined in 
Table 5.5.1.4.3.1 shall apply. 

In case the mobile station has no information available to determine whether PBCCH is allocated in the cell or not, the 
mobile station shall transmit the PACKET SI STATUS message where an empty Received SI Message List is indicated. 
Upon reception of such message, the network shall determine that the mobile station has no knowledge whether 
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PBCCH is present in the cell. In this case the network shall start transmitting the PSI messages if PBCCH is present in 
the cell or, otherwise, SI messages. 

The mobile station may request the release of the RR connection and packet resources (e.g. if combined RAU procedure 
shall be performed after the release of the RR connection) with PS_REL_REQ field sent in the PACKET SI STATUS 
(respectively PACKET PSI STATUS) message. 

On receipt of the PACKET SI STATUS (respectively PACKET PSI STATUS) message the network shall send the 
missing system information messages by using the PACKET SERVING CELL SI message or it shall send respectively 
the corresponding packet system information messages. 

The mobile station is allowed to send the PACKET SI STATUS (respectively PACKET PSI STATUS) message twice 
and the second sending occurrence of this message shall take place at the first suitable opportunity at least one second 
after the first transmission of that message. Whenever the mobile station has received all required system information 
(respectively packet system information) messages, it shall send the PACKET SI STATUS (respectively PACKET PSI 
STATUS) message at the first suitable opportunity, even if it has already sent the PACKET SI STATUS (respectively 
PACKET PSI STATUS) twice. 

When the network receives the PACKET SI STATUS (respectively PACKET PSI STATUS) message indicating that all 
required system information (respectively packet system information) messages have been received by the mobile 
station it shall stop timer T3197, start timer T3I09 (see 3GPP TS 44.018) and send the CHANNEL RELEASE message 
on the main DCCH indicating that the mobile station is allowed to continue in packet transfer mode after the release of 
the RR connection (see 3GPP TS 44.018). 

If continuous timing advance parameters are provided to the mobile station in the PACKET CS RELEASE 
INDICATION message, the mobile station shall start the continuous timing advance procedure upon entering packet 
transfer mode. The mobile station shall use the last timing advance value received whilst in dual transfer mode until a 
new value of the timing advance is provided to the mobile station according to the procedures defined for packet 
transfer mode. 

If timer T3 197 expires before the network receives the PACKET SI STATUS (respectively PACKET PSI STATUS) 
message indicating that all required system information (respectively packet system information) messages have been 
received by the mobile station, the network shall release the RR connection by sending the CHANNEL RELEASE 
message on the main DCCH indicating that the mobile station is not allowed to continue in packet transfer mode after 
the release of the RR connection (see 3GPP TS 44.018). 

5.5.1 .2 System information on PBCCH 

If PBCCH is present in the serving cell, the mobile station shall receive the PACKET SYSTEM INFORMATION (PSI) 
messages broadcast on PBCCH. The parameters determining the schedule of PSI messages on PBCCH are provided in 
the PSIl message. 

When a new cell has been selected where PBCCH is present, the mobile station shall perform a complete acquisition of 
PBCCH messages (see 5.5.1.4). The mobile station shall not perform packet access in the selected cell, or enter the 
packet transfer mode or the MAC-Shared state, until it has: 

- acquired the PACKET SYSTEM INFORMATION TYPE 1 (PSIl) message; 

acquired a consistent set of PSI2 messages; and 

made at least one attempt to receive the complete set of PSI messages on PBCCH. 

If the network supports the PACKET PSI STATUS message, the mobile station may perform packet access or maintain 
its radio resources (PDCH(s)) when the RR connection is released while in dual transfer mode, and enter packet transfer 
mode or the MAC-Shared state, as soon as the PSIl message and a consistent set of PSI2 messages have been received. 
In this case, the mobile station shall implement the request for acquisition of system information (see 5.5.1.4.3). 

When the PSIl message has been received, the mobile station shall supervise the PBCCH_CHANGE_MARK and 
perform update of PBCCH information as specified in sub-clause 5.5.1.2.1. In addition, while camping on a cell, the 
mobile station shall take into account any PSI message that may be received on PCCCH and PACCH. 

Once that the mobile station starts to acquire the information on PBCCH, the information sent to a mobile station in 
RLC/MAC control messages shall be independent of the information provided on the BCCH. If the mobile station 
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receives information in an RLC/MAC control message that depends on the BCCH information, the behaviour of the 
mobile station is not specified. 

5.5.1 .2.1 Supervision of PBCCH_CHANGE_MARK and update of PBCCH information 

While camping on a cell where PBCCH is present, the mobile station shall attempt to receive the PSIl message at least 
every 30 seconds. The mobile station shall then take into account any occurrence of the PSIl message that may be 
received on PACCH during packet transfer mode or MAC-Shared state. The mobile station shall also take into account 
any occurrence of the PSIl message that may be received on PCCCH during periods in packet idle mode or MAC-Idle 
state. If the PSIl message is not received, the mobile station shall attempt to receive this message on PBCCH during 
periods in packet idle mode or MAC-Idle state. 

If the mobile station has not received the PSIl message within the last 30 seconds, it shall attempt to receive the PSIl 
message each time it is scheduled on PBCCH. Such attempts shall be made during packet idle mode, packet transfer 
mode, MAC-Idle state and MAC Shared state. A mobile station in packet transfer mode or MAC-Shared state may 
suspend its TBF(s) for this purpose (see 5.5.1.4.2). 

The PSIl message contains the PBCCH_CHANGE_MARK and PSI_CHANGE_FIELD parameters. The mobile station 
shall store the value of the last PBCCH_CHANGE_MARK received. 

If the mobile station receives a PBCCH_CHANGE_MARK and detects that the value has been incremented by one 
unit, compared to the previous value, the mobile station shall perform a partial acquisition of PBCCH information. The 
information that shall be received is determined by the PSI_CHANGE_FIELD parameter: 

If the PSI_CHANGE_FIELD parameter indicates an update of a specific type or specific types of PSI messages, 
the mobile station shall receive at least one instance of each of the indicated type(s) of PSI messages. 

If the PSI_CHANGE_FIELD parameter indicates an update of an unspecified type or types of PSI messages, the 
mobile station shall receive at least one message instance within each consistent set of PSI messages on PBCCH. 
It shall also receive all PSI messages on PBCCH not belonging to a consistent set. 

If the PSI_CHANGE_FIELD parameter indicates an update of an unknown type of PSI message, the mobile 
station is not required to receive any PBCCH information. 

When a PSI message is received, the mobile station shall consider the PSI change mark value, if such is received in the 
message and take appropriate action (see sub-clause 5.5.1.4.1). 

Whenever the mobile station receives a PBCCH_CHANGE_MARK and detects that the value has been incremented by 
more than one unit, compared to the previous value, the mobile station shall perform a complete acquisition of PBCCH 
messages (see sub-clause 5.5.1.4). 

5.5.1 .2.2 Replacement of PBCCH 

The mobile station may receive a PSIl message indicating that PBCCH is being deactivated in the cell. Moreover, the 
mobile station may receive a PSI 13 message on PACCH or PCCCH providing a different PBCCH description than the 
one currently being used, or a PSI 13 message indicating that PBCCH is not present in the cell. 

If the mobile station detects that PBCCH is being deactivated in the cell, or receives an indication that PBCCH is no 
longer present in the cell, it shall attempt to receive the SI 13 message on BCCH. For this purpose, the mobile station 
may suspend its operation in packet idle mode, packet transfer mode, MAC-Idle state and MAC-Shared state (see 
5.5.1.4.2). When the SI13 has been received, further action depends on the contents of the SI13 message: 

If the SI13 message contains a PBCCH description, the mobile station shall perform a complete acquisition of 
PBCCH messages using the indicated PBCCH (see sub-clause 5.5.1.4). 

If the SI13 message does not contain a PBCCH description, the mobile station shall perform a complete 
acquisition of BCCH messages. 

If the mobile station receives a PSIl 3 message with a PBCCH description different from that currently being 
used, the mobile station shall perform a complete acquisition of PBCCH messages using the new PBCCH. 
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5.5.1.2.3 PSI1 reception failure 

If the mobile station has not received the PSIl message within the last 60 s, a PSIl reception failure has occurred. A 
PSIl reception failure shall result in a cell reselection. 

5.5.1 .3 System information on BCCH 

The presence of a PBCCH in the cell is indicated by a PBCCH description in the SI13 message on BCCH. If the mobile 
station receives an SI 13 message without a PBCCH description, it shall assume that PBCCH is not present in the cell. If 
PBCCH is not present in the serving cell, the mobile station shall receive the SYSTEM INFORMATION (SI) messages 
broadcast on BCCH. 

When a new cell has been selected where PBCCH is not present, the mobile station shall perform a complete 
acquisition of BCCH messages (see sub-clause 5.5. 1 .4). The mobile station shall not perform packet access in the 
selected cell, or enter the packet transfer mode, until it has: 

- acquired the SYSTEM INFORMATION TYPE 3 (SI3), SI13 and, if present, SIl messages; 

made at least one attempt to receive other SI messages that may be scheduled within one TC cycle on BCCH 
(see 3GPP TS 45.002). 

If the network supports the PACKET SI STATUS message, the mobile station may perform packet access or maintain 
its radio resources (PDCH(s)) when the RR connection is released while in dual transfer mode, and enter packet transfer 
mode, as soon as the SI3, SI13 and, if present, SIl messages have been received. In this case, the mobile station shall 
implement the request for acquisition of system information (see sub-clause 5.5.1.4.3). 

When the SI 13 message has been received, the mobile station shall supervise the BCCH_CHANGE_MARK and 
perform update of BCCH information. 

5.5.1 .3.1 Supervision of BCCH_CHANGE_MARK and update of BCCH information 

While camping on a cell where PBCCH is not present, the mobile station shall attempt to receive the SIl 3 or the PSIl 3 
message at least every 30 s. The mobile station shall then take into account any occurrence of the PSI13 message that 
may be received on PACCH during packet transfer mode. If PSI13 is not received, the mobile station shall attempt to 
receive the SIl 3 message on BCCH during periods in packet idle mode. 

If the mobile station has received neither the SI13 nor the PSI13 message within the last 30 s, it shall attempt to receive 
the SI13 message each time it is scheduled on BCCH. Such attempts shall be made during both packet idle and packet 
transfer modes. A mobile station in packet transfer mode may suspend its TBF(s) for this purpose (see sub- 
clause 5.5.1.4.2). 

The SI13 and PSI13 messages contain the BCCH_CHANGE_MARK and SI_CHANGE_FIELD parameters. When 
camped on a cell where PBCCH is not present, the mobile station shall store the value of the last 
BCCH_CHANGE_MARK received. In that case, if the mobile station detects that the value has been incremented by 
one unit, compared to the previous value, the mobile station shall perform ?i partial acquisition of BCCH information. 
The information that shall be received is determined by the SI_CHANGE_FIELD parameter: 

If the SI_CHANGE_FIELD parameter indicates an update of a specific type or specific types of SI messages, the 
mobile station shall receive at least one instance of each of the indicated type(s) of SI messages. 

If the SI_CHANGE_FIELD parameter indicates an update of an unspecified type or types of SI messages, the 
mobile station shall receive at least one message instance within each consistent set of SI messages on BCCH. It 
shall also receive all SI messages on BCCH not belonging to a consistent set. 

If the SI_CHANGE_FIELD parameter indicates an update of an unknown type of SI message, the mobile station 
is not required to update any BCCH information. 

When an SI message is received, the mobile station shall consider a SI change mark value, if such is received in the 
message and take appropriate action (see sub-clause 5.5.1.4.1). 

If the mobile station detects that the BCCH_CHANGE_MARK value has been incremented by more than one unit, 
compared to the previous value, the mobile station shall perform a complete acquisition of BCCH messages (see sub- 
clause 5.5.1.4). 
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5.5.1 .3.2 Establishment of PBCCH 

The mobile station may receive an SI 13 or PSI13 message providing a PBCCH description indicating that PBCCH is 
present in the cell. The mobile station shall then perform a complete acquisition of PBCCH messages using the 
indicated PBCCH (see sub-clause 5.5.1.4). 

5.5.1 .3.3 SI1 3 reception failure 

If the mobile station has not received the SI13 or the PSI13 message within the last 60 s, a SI13 reception failure has 
occurred. An SI 13 reception failure shall result in a cell reselection. 

5.5.1 .4 Acquisition of system information on the broadcast channel 

This procedure shall be used by a mobile station that supports GPRS (in A/Gb mode) or lu mode in order to perform a 
complete or partial acquisition of either PBCCH or BCCH information. As part of this procedure, the mobile station 
may implement the request for acquisition of system information as specified in sub-clause 5.5.1.4.3. 

When PBCCH is not present in a cell this procedure starts: 

when the mobile station is camped on BCCH and receives a BCCH_CHANGE_MARK or SI change mark value 
indicating that system information is changed. 

When PBCCH is present in a cell this procedure starts: 

when the mobile station is camped on PBCCH and receives a PBCCH_CHANGE_MARK or PSI change mark 
value indicating that packet system information is changed. 

Moreover, the procedure shall start at any other indication, which may be received by the mobile station, that the stored 
system information for the serving cell is no longer valid. 

At cell selection or cell reselection, in case PBCCH is present in the target cell, this procedure starts when the mobile 
station starts to receive the information on PBCCH. In case PBCCH is not present in the target cell, the procedure starts 
when the mobile station has received the SI13 message. 

In a complete acquisition of either PBCCH or BCCH information, the mobile station shall receive all PSI or SI 
messages that are scheduled on the respective broadcast channel. The mobile station shall delete any PSI or SI change 
mark value that was stored before the acquisition of PBCCH or BCCH information started. 

In ?i partial acquisition of either PBCCH or BCCH information, only a certain subset of the PSI or SI messages that are 
scheduled on the respective broadcast channel shall be received. The mobile station may consider the state of the PSI or 
SI change mark values, without restriction, to reduce the total number of messages to receive. 

When the mobile station acquires a set of PSI or SI messages on the respective broadcast channels, it may receive these 
messages during packet idle mode, packet transfer mode, MAC-Idle state, MAC-Shared state and broadcast/multicast 
receive mode. While the mobile station is in packet idle mode or MAC-Idle state or broadcast/multicast receive mode if 
the network has indicated that the system information is not sent on the PACCH, an attempt to receive a required 
message shall be made each time the message is scheduled on the broadcast channel, until the message is received. 
While the mobile station is in packet transfer mode, MAC-Shared state or broadcast/multicast receive mode if the 
network has indicated that the system information is sent on the PACCH, it shall receive any PSI message that is sent 
by the network on PACCH. While the mobile station is in dual transfer mode or MAC-DTM state, it may disregard any 
PSI message except PSI14 message that is sent by the network on PACCH. 

If the mobile station has not received the required messages within 10 seconds after the start of this procedure, an 
attempt to receive a missing message shall be made each time the message is scheduled on the broadcast channel. These 
attempts shall then be performed during packet idle mode, packet transfer mode, MAC-Idle state, MAC-Shared state 
and broadcast/multicast receive mode. A mobile station in packet transfer mode or MAC-Shared state may suspend its 
TBF(s) for this purpose, as specified in 5.5.1.4.2. A mobile station in broadcast/multicast receive mode may skip the 
reception of radio blocks of the MBMS radio bearer for the same purpose, as specified in 5.5.1.4.2. 

A second acquisition of either PBCCH or BCCH information may be initiated (e.g. when the mobile station receives a 
PSI or SI change mark value) before a previous acquisition is completed. In this case, the mobile station shall discard 
and immediately begin re-acquiring all the system information messages of the particular type to which the changemark 
value refers. 
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To allow future extension of PSI message types, the mobile station may disregard a message in a position within the 
schedule of PSI messages on PBCCH, where it receives a valid RLC/MAC control block, but diagnoses an unknown or 
unexpected (non-PSI) message type. When this condition is detected, the mobile station needs not to receive the 
PBCCH block in this position again, until a change in the schedule of PBCCH messages is detected or a complete 
acquisition of PBCCH information is required. 

5.5.1 .4.1 Consistent sets of system information messages 

A mobile station, receiving a PSI or SI message belonging to a consistent set of system information messages, shall 
store the last PSI or SI change mark value received for the set of messages (see table 5.5.2.1.4.1). A mobile station 
lacking all non-GSM capabilities defined for PSI6, PSI7, SI 18 or SI 20 shall consider those message as irrelevant when 
making a determination of whether or not a consistent set of system information messages has been received. 

A mobile station lacking UTRAN capabilities shall consider a PSBquater message as irrelevant when making a 
determination of whether or not a consistent set of system information messages has been received. 

Whenever mobile station receives a PSI or SI change mark value, which is not equal to the previously stored value for 
the set of messages, the mobile station shall perform ?i partial acquisition of either PBCCH or BCCH information. It 
shall then receive all instances of the PSI or SI messages belonging to the consistent set of system information 

messages. 

If a mobile station detects an inconsistency amongst the PSI or SI count and index parameters within a consistent set of 
system information messages or any other inconsistency making the information that is contained invalid, the mobile 
station shall discard the messages received so far and delete the stored PSI or SI change mark value. The mobile station 
may then restart the acquisition of the affected system information messages. 

5.5.1 .4.2 Suspension of operation to receive system information 

During certain conditions, the mobile station in packet transfer mode or MAC-Shared state is allowed to suspend its 
TBF(s) to receive certain information on PBCCH or BCCH. A mobile station in broadcast/multicast receive mode may 
suspend the reception of radio blocks of the MBMS radio bearer for the same purpose. Such suspension is made without 
notification to the network. 

Suspension of its TBF(s) or suspension of the reception of radio blocks of the MBMS radio bearer for this purpose is 
allowed during the time required, for each message and according to the mobile station's multislot class, to receive the 
required messages on PBCCH or BCCH. The allowable suspension of an uplink TBF may be extended with one block 
period, in case of dynamic or extended dynamic allocation, if the mobile station is unable to receive the corresponding 
USE due to the suspension of downlink operation. In case it conflicts with the transmission of a polling response, 
priority shall be given to the acquisition of blocks on the PBCCH or BCCH channel. 

5.5.1 .4.3 Request for acquisition of system information 

As an option, the mobile station may implement the request for acquisition of system information. If the network 
supports the PACKET PSI STATUS message or the PACKET SI STATUS message, the mobile station shall then send 
the PACKET PSI STATUS message to the network, each time an acquisition of PBCCH information is initiated or the 
PACKET SI STATUS message to the network, each time an acquisition of BCCH information is initiated. 

A mobile station supporting the Network Assisted Cell Change or enhanced DTM CS release procedures shall 
implement the request for acquisition of system information (see sub-clauses 5.5.1.1a and 5. 5. 1.1b. 5). 

The PACKET SI STATUS message shall always contain the PSCSI_SUPPORT field. 

The PACKET PSI STATUS (respectively PACKET SI STATUS) message shall indicate the present status of PSI 
(respectively SI) messages stored in or requested but not received by the mobile station. The mobile station shall 
include as many PSI (respectively SI) message types that fit into the Received PSI Message List (respectively Received 
SI Message List) construction in the PACKET PSI STATUS (respectively PACKET SI STATUS) message and that 
meet the following criteria: 

The PSI (respectively SI) message type is relevant for the mobile station, based on the features the mobile station 
supports (e.g. non-GSM and multi-RAT capabilities); and 

In case of optional PSI (respectively SI) messages types, the PSI (respectively SI) message type shall be 
indicated by the network as present on PBCCH (respectively BCCH). 
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If the presence of an optional PSI (respectively SI) message type cannot be determined, based on the information 
received, the mobile station shall assume that the optional PSI (respectively SI) message type is present. 

NOTE 1: On PBCCH, the presence of optional PSI messages is indicated in PSIl and PSI2. 

NOTE 2: On BCCH, SI2, SB, SI4 and, if present, SI9 indicate the presence of optional SI messages, except SIl. 
The presence of SIl can be determined by reading the BCCH Norm block at TC = 0. 

The "ADDITIONAL_MSG_TYPE" information should reflect whether all PSI (respectively SI) message types that 
satisfy the criteria given above fit into a given PACKET PSI STATUS (respectively PACKET SI STATUS) message or 
not. 

The message type value for these PSI (respectively SI) messages shall be included in the Received PSI Message List 
(respectively Received SI Message List) in the PACKET PSI STATUS (respectively PACKET SI STATUS) message. 
The message types that may be indicated are given in table 5.5.1.4.3.1. The message types shall be indicated in 
descending order of priority. The network may use this information to determine which PSI (respectively SI) message 
types the mobile station is able to receive and the present status of the PSI (respectively SI) messages stored in the 
mobile station. 

Table 5.5.1.4.3.1 : Message types that may be indicated at a request for acquisition of system 

information during packet transfer mode 



Type of status message 


PSI (respectively SI) message types, descending order of priority 


PACKET PSI STATUS 
message 


PSI2 (highest priority), PSI3, PSISbis, PSI5, PSISter, PSISquater, PSI6, 
PSI7, and PSI8 (lowest priority) 


PACKET SI STATUS 
message 


SI1 (highest priority), SIS, SI2, SI2bis, SI2ter, SI2quater, SI4, SI2n, SI7, 
SIS, SI9, SI15, SI16, SI17, SI1S, SI20 and SI19 (lowest priority) 



During a partial acquisition of PSI (respectively SI) messages, see sub-clause 5.5.1.4, the mobile station may need to 
obtain the current PSI (respectively SI) change mark value for certain types of PSI (respectively SI) messages. In that 
case, the mobile station may use this procedure and indicate the present status for that PSI (respectively SI) message 
type in the PACKET PSI STATUS (respectively PACKET SI STATUS) message, except that the message instance 
corresponding to the PSI (respectively SI) index parameter = shall be indicated as not received. 

The PACKET PSI STATUS (respectively PACKET SI STATUS) message may also be used to indicate the message 
type of a PSI (respectively SI) message that is required but has not been received by the mobile station. 

The PACKET PSI STATUS (respectively PACKET SI STATUS) message is sent on PACCH when the mobile station 
is in packet transfer mode or MAC-Shared state. The first sending of this message during the acquisition of PBCCH 
(respectively BCCH) information shall take place at the first suitable opportunity after the acquisition is initiated. 

During the acquisition of PBCCH (respectively BCCH) information, up to four PACKET PSI STATUS (respectively 
PACKET SI STATUS) messages may be sent to the network. The second sending occurrence of this message shall take 
place at the first suitable opportunity at least one second after that the message is sent the first time. Further sending 
occurrences shall take place at the first suitable opportunity at least two seconds after that the message was sent the 
previous time. At each sending occurrence, this message shall be updated according to the present status of PSI 
(respectively SI) messages in the mobile station. 

The PACKET PSI STATUS (respectively PACKET SI STATUS) message shall not be sent when the mobile station 
has started to suspend its TBF(s) in order to receive the required PSI (respectively SI) messages on PBCCH 
(respectively BCCH). The PACKET PSI STATUS (respectively PACKET SI STATUS) message shall not be sent 
when the mobile station has acquired the complete set of PSI (respectively SI) messages on PBCCH (respectively 
BCCH), unless a new partial or full acquisition of system information is required. 

5.5.1.5 Discontinuous reception (DRX) 

A mobile station in packet idle mode shall listen to the radio blocks on CCCH or PCCCH as defined in 
3GPP TS 45.002. 

In the GPRS attach procedure, defined in 3GPP TS 24.008, the mobile station requests values for the 
SPLIT_PG_CYCLE and NON_DRX_TIMER parameters to be applied on CCCH or PCCCH. 

NOTE: The support of the SPLIT_PG_CYCLE parameter is optional on CCCH, see 3GPP TS 45.002. 
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The SPLIT_PG_CYCLE and NON_DRX_TIMER parameters control: 

the occurrence of paging blocks on CCCH or PCCCH belonging to the mobile station (SPLIT_PG_CYCLE 
parameter, see 3GPP TS 45.002) in DRX mode (see 3GPP TS 43.064); and 

the duration of the non-DRX mode period to be applied by the mobile station when it has left the packet transfer 
mode or the dual transfer mode and then enters the packet idle mode. 

There are five cases when the mobile station shall enter a non-DRX mode period. 

1) At the transition from the packet transfer mode to the packet idle mode, the mobile station shall enter the 
Transfer non-DRX mode period. 

2) At the transition from the dual transfer mode to the dedicated mode or packet idle mode, the mobile station shall 
enter the Transfer non-DRX mode period. 

In both cases, the duration of the Transfer non-DRX mode period is determined by value of the 
NON_DRX_TIMER parameter, requested in the GPRS attach procedure, and the value of the 
DRX_TIMER_MAX parameter broadcast in the cell. The mobile station may use the minimum value of these 
two parameters. 

If the mobile station receives a new value of the DRX_TIMER_MAX parameter during the Transfer non-DRX 
mode period, the mobile station may wait to apply the new value until the next time the Transfer non-DRX mode 
period is entered. 

3) A mobile station operating in NC2 mode shall enter the NC2 non-DRX mode period when it sends an NC 
measurement report. The duration of this period is defined by the NC_NON_DRX_PERIOD parameter. 

4) When initiating the MM procedures for GPRS attach and routeing area update defined in 3GPP TS 24.008, the 
mobile station shall enter the MM non-DRX mode period. This period ends when either of the messages GPRS 
ATTACH ACCEPT, GPRS ATTACH REJECT, ROUTING AREA UPDATE ACCEPT or ROUTING AREA 
UPDATE REJECT is received by the mobile station. This period also ends after timeout when waiting for any of 
these messages. 

5) The mobile station shall enter the MBMS non-DRX mode period when it receives a pre-notification for an 
MBMS service and MBMS session, and the MBMS service is a broadcast service or is a multicast service 
previously joined by the mobile station and the MBMS session has not yet been received by the mobile station. 
The mobile station shall also enter the MBMS non-DRX mode period, if not already in it, when the mobile 
station sends the MBMS SERVICE REQUEST message. The mobile station shall also enter the MBMS non- 
DRX mode period, if not already in it, when it receives a notification for an MBMS service and MBMS session, 
and the MBMS service is a broadcast service or is a multicast service previously joined by the mobile station and 
the MBMS session has not yet been received by the mobile station, and the notification: 

indicates that no counting shall be performed and contains no MBMS p-t-m channel description; 

or, specifies an MBMS radio bearer starting time which has not yet elapsed. 

The MBMS non-DRX mode period ends when a notification (containing an MBMS p-t-m channel description) 
or the MBMS ASSIGNMENT message, addressing the same MBMS session and not specifying an MBMS radio 
bearer starting time or specifying an MBMS radio bearer starting time already elapsed, is received by the mobile 
station. If the notification or the MBMS ASSIGNMENT message specifies an MBMS radio bearer starting time 
which has not yet elapsed, the period ends when the point in time denoted by the MBMS radio bearer starting 
time occurs, unless any subsequent notification or MBMS ASSIGNMENT message addressing the same MBMS 
session and received by the mobile station, before the point in time denoted by the MBMS radio bearer starting 
time, provides an up-to-date value of the MBMS radio bearer starting time or does not include an MBMS radio 
bearer starting time. 

The MBMS non-DRX mode period also ends after timeout when waiting for the MBMS notification of the pre- 
notified MBMS service and MBMS session or after timeout when waiting for the MBMS ASSIGNMENT 

message. 

The non-DRX mode periods defined above run independent of each other and may overlap. The non-DRX mode 
periods have effect only in packet idle mode. In packet idle mode, the mobile station shall be in non-DRX mode during 
any of the non-DRX mode periods. Otherwise, the mobile station in packet idle mode may be in DRX mode. 
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If the mobile station establishes an RR connection during any of the non-DRX mode periods, then that period shall 
continue to run. 

5.5.1 .6 Page mode procedures on PCCCH 

The network sends page mode information in all downlink message on PCCCH (and PACCH, see note). The page 
mode information controls possible additional requirements on a mobile station receiving the message. 

NOTE: PCCCH, PDTCH and PACCH may be operated in frame stealing mode on the same PDCH. A mobile 

station in packet idle mode or MAC-Idle state shall consider any RLC/MAC control message received in 
such a radio block as belonging to PCCCH. A mobile station in packet transfer mode, dual transfer mode, 
MAC-Shared state or MAC-DTM state shall consider any RLC/MAC control message received as 
belonging to PACCH. 

A mobile station in packet transfer mode, dual transfer mode, MAC-Shared state or MAC-DTM state shall not consider 
the page mode information received in any message that is received on a PDCH. 

A mobile station in packet idle mode or MAC-Idle state shall take into account the page mode information in any 
message received in a radio block on PCCCH corresponding to its paging group. The mobile station shall not take into 
account the page mode information in a message received in any other radio block than those corresponding to its 
paging group. The requirements yielded by the page mode information are as follows: 

normal paging: no additional requirements; 

extended paging: the mobile station is required in addition to receive and analyse the possible message in the 
third block period on PCCCH where paging may occur (PPCH), following the block corresponding to MS's 
paging group; 

- paging reorganization: The mobile station shall receive all messages on the PCCCH regardless of the 

BS_PAG_BLKS_RES setting. It is required to receive all PBCCH messages. When the mobile station receives 
the next message to its (possibly new) paging group, subsequent action is defined by the page mode information 
in that message; 

satne as before: no change of page mode from the previous page mode. 

Note that a mobile station takes into account the page mode information only in packet idle mode or MAC-Idle state 
and only in messages received in a radio block corresponding to its paging group, whatever the currently applied 
requirements are (normal paging, extended paging or paging reorganization). 

When the mobile station selects a new PPCH, the initial page mode in the mobile station shall be set to paging 
reorganization. If an RLC/MAC block in a paging sub-channel does not contain page mode information, or if it is not 
received correctly, the default page mode information is same as before. 

5.5.1.7 Frequency Parameters 

Frequency parameters may be included in the packet assignment messages (i.e., 
PACKET DOWNLINK ASSIGNMENT, MULTIPLE THE DOWNLINK ASSIGNMENT, 
PACKET UPLINK ASSIGNMENT, MULTIPLE TEE UPLINK ASSIGNMENT, PACKET TIMESLOT 
RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or PACKET CS RELEASE INDICATION 
messages) and define the radio frequency channels or set of radio frequency channels the mobile station is to use during 
the assigned TBF(s). The first assignment message, sent to the mobile station when it enters packet transfer mode or 
MAC-Shared state, shall include the frequency parameters. Subsequent assignment messages, sent to the mobile station 
during packet transfer mode or MAC-Shared state, may omit the frequency parameters. If a mobile station receives a 
subsequent assignment message, during packet transfer mode or MAC-Shared state, without the frequency parameters, 
the mobile station shall continue to use the previously assigned frequency parameters. 

NOTE 1 : A packet assignment message, when sent to a mobile station in dual transfer mode or MAC-DTM state, 
shall not include the frequency parameters. If the network intends to change the frequency allocation of a 
mobile station in dual transfer mode or MAC-DTM state, the network may use the DTM assignment 
procedure defined in 3GPP TS 44.018. 
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The Frequency Parameters information element is defined in sub-clause 12.8. The frequency parameters may use an 
ARFCN defining a non-hopping radio frequency channel, or use the indirect encoding, direct encoding 1 or direct 
encoding 2 defining a hopping radio frequency channel. 

The indirect encoding defines the assigned set of radio frequency channels by referencing information stored within the 
mobile station. Such information maybe received on PBCCH or BCCH (see sub-clauses 5.5.2.1, 11.2.19, 12.8 and 
12. 10a and 3GPP TS 44. 160,), or be received in a previous assignment message using one of the direct encoding 
options. An MA_NUMBER identifies which of up to eight stored sets of frequency parameters is to be used. The 
MA_NUMBER shall use the following coding: 

MA_NUMBER = 0-13 shall be used to reference a GPRS mobile allocation received in a PSI2 message; 

MA_NUMBER = 14 shall be used to reference a GPRS mobile allocation received in a SI13 or PSI13 message; 

MA_NUMBER =15 shall be used to reference a GPRS mobile allocation received in a previous assignment 

message using the direct encoding. 

When the indirect encoding is used, the network may include a CHANGE_MARK_1 and a CHANGE_MARK_2 in the 
Frequency Parameters information element. The mobile station shall then verify that it is using a set of PBCCH or 
BCCH information identified by a PSI or SI change mark corresponding to one of the CHANGE_MARK_1 or 2 
parameters, for the decoding of the frequency information. If that is not the case, an abnormal condition occurs. 

The direct encoding defines the assigned set of radio frequency channels by using information contained within the 
assignment message. The direct encoding 1 references the cell allocation or reference frequency lists received on 
PBCCH for the decoding of this information. The direct encoding 2 is self contained. When the direct encoding 1 or 2 is 
used, the mobile station shall store the received GPRS mobile allocation for possible later reference in an assignment 
message using the indirect encoding. Such reference shall be made using the MA_NUMBER = 15. 

NOTE 2: If there is a GPRS mobile allocation associated with MA_NUMBER = 15, the association shall be kept 

unchanged if the mobile station receives a packet assignment using the indirect encoding (referencing any 
value of the MA_NUMBER), the frequency parameters are not included in the packet assignment (i.e., in 
packet transfer mode, dual transfer mode, MAC-Shared state or MAC-DTM state) or the mobile station 
establishes an RR connection (for A/Gb mode) or is allocated a DBPSCH (for lu mode). 

For the decoding of frequency parameters, the mobile station shall be able to store the following frequency information 
(see sub-clauses 11.2.19, 12.8 and 12.10a): 

four Reference Frequency Lists received in the PSI2 information and the corresponding RFL_NUMBERs for 
identification, each RFL having a contents length of up to 18 octets; 

a Cell Allocation received in the PSI2 information referencing up to four RFLs; 

seven GPRS Mobile Allocations received in the PSI2 or the SI13/PSI13 information and the corresponding 
MA_NUMBERs for identification, each GPRS Mobile Allocation information element having a length of up to 
12 octets (96 bits); and 

one GPRS mobile allocation received in an assignment message using direct encoding 1 or 2, consisting of either 
a GPRS Mobile Allocation information element having a length of up to 12 octets (96 bits) or a MA Frequency 
List having a contents length of up to 18 octets. 

The mobile station shall be able to store the frequency information for the PCCCH description corresponding to its own 
PCCCH_GROUP (see sub-clause 11.2.19). 

If the mobile station supports SMSCB, it shall be able to store the frequency information for the CBCH to be used in 
packet idle mode or MAC-Idle state. 

The frequency information that the mobile station has stored while camping on a cell shall be deleted when the mobile 
station reselects a new cell. 

5.5.1.8 TLLI management 

In case the mobile station receives a message assigning a new P-TMSI from the network during the contention 
resolution procedure, the mobile station shall continue to use the old TLLI until the contention resolution is completed. 
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After contention resolution the mobile station shall apply new TLLI in RLC/MAC control block if the mobile has 
received a new P-TMSI. 

The BSS shall not include TLLI within RLC/MAC control messages it sends to a mobile station in packet transfer 
mode. 

5.5.1 .9 Packet Flow Context (PFC) 

Packet Flow Context (PFC) procedures are described in 3GPP TS 23.060. A Packet Flow Identifier (PFI) is used to 
identify a PFC. 

Network support of packet flow context (PFC) procedures is indicated by the PFC_FEATURE_MODE parameter that 
is broadcast on either the BCCH or PBCCH. If the PFC_FEATURE_MODE field indicates that the network does not 
support PFC procedures then a mobile station shall not indicate a PFI value during uplink TBF establishment. If the 
PFC_FEATURE_MODE field indicates that the network supports PFC procedures then a mobile station may indicate a 
PFI value during uplink TBF establishment. The PFI value identifies the initial PFC used during the TBF. 

If the network indicates it supports multiple TBF procedures (see sub-clause 7.0) then it shall also indicate support for 
PFC procedures. When the network and the mobile station both support multiple TBF procedures then the mobile 
station shall indicate the PFI value associated with each uplink TBF it attempts to establish and the network shall 
indicate the PFI value associated with each downlink TBF it attempts to establish. 

A network or mobile station that supports PS handover shall also support PFC procedures. 

In case no valid PFI value is allocated for the LLC data to be transmitted, and the network indicates support for the PFC 
procedures, an MS supporting PFC procedures shall associate and indicate the following PFI values for the LLC data: 

PFI=0 (Best Effort) for user data, 

PFI=I (SignalHng) for GMM/SM signalHng (LLC SAPI 1), or 

PFI=2 (SMS) for Short Message Service (LLC SAPI 7), or 

PFI=3 (TOM8) for LLC SAPI 8 data. 

5.5.2 Network side 

5.5.2.1 System Information broadcasting 

5.5.2.1 .1 System information on PBCCH 

If PBCCH is present in the cell, the network regularly broadcasts PACKET SYSTEM INFORMATION TYPE (PSI) I, 
2, 3 and 3bis messages, and optionally PSBter, PSBquater and some types of PSI messages on the PBCCH. The PSI 2, 
PSI 3bis, PSI3 ter, PSBquater messages and some further types of PSI messages may be broadcast in multiple number 
of instances. Based on the information broadcast in PSI messages, the mobile station is able to decide whether and how 
it may gain access to the system via the current cell. 

NOTE: The network should take into account the limitations of earlier version of mobile equipments to 
understand the 3-digit MNC format of the location area identification, see sub-clause 12.23 and 
3GPP TS 44.018, table "Location Area Identification .information element". 

Instances of the PSI 5 message are broadcast on PBCCH if the mobile stations camping on the cell shall perform 
measurement reporting, see 3GPP TS 45.008. 

Instances of the PSI6 and PSI7 message may be broadcast on the PBCCH if non-GSM broadcast information is 
transmitted. 

The PSI8 message may be broadcast on the PBCCH if additional information (i.e. CBCH configuration and dynamic 
ARFCN mapping) shall be provided to the mobile station camping on the cell. 

The PSIl message contains the PBCCH_CHANGE_MARK and PSI_CHANGE_FIELD parameters. The value of the 
PBCCH_CHANGE_MARK may be incremented by one, modulo 8, each time the network makes a change in the 
PBCCH information. Such change includes any addition, removal or replacement of PSI messages, contents of PSI 
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messages, or change in the scheduling of PSI messages on PBCCH. A change in the contents of the PSIl message alone 
shall not be reflected in the PBCCH_CHANGE_MARK. When the PBCCH_CHANGE_MARK is incremented, the 
PS1_CHANGE_FIELD parameter shall be set to an appropriate value to indicate the nature of the latest change in the 
PBCCH information. 

The network may increment the PBCCH_CHANGE_MARK value by more than one, modulo 8, in order to enforce a 
complete acquisition of PBCCH information of all mobile stations. 

In order to avoid extensive TBF suspensions following an increment of the PBCCH_CHANGE_MARK parameter, the 
network may send PSI messages on PACCH to mobile stations in packet transfer mode. 

The network indicates the support of the PACKET PSI STATUS and EGPRS PACKET CHANNEL REQUEST 
messages in the PSIl message. 

5.5.2.1 .2 System information on BCCH 

In addition to the requirements in 3GPP TS 44.018, a SYSTEM INFORMATION TYPE 13 (SI13) message is regularly 
broadcast by the network on the BCCH to support GPRS. Optionally and if PBCCH is not present in the cell, additional 
types of SI messages may be broadcast on BCCH. Some of them may be broadcast in multiple number of instances. If 
PBCCH is present in the cell, only the SI 13 message is required on BCCH to support GPRS. 

Based on this information, the GPRS mobile station is able to decide whether and how it gains access to the system via 
the current cell when PBCCH is not present. 

The SI13 message contains the BCCH_CHANGE_MARK and SI_CHANGE_FIELD parameters. If PBCCH is not 
present in the cell, the value of the BCCH_CHANGE_MARK may be incremented by one, modulo 8, each time the 
network makes a change in the BCCH information. Such change includes any addition, removal or replacement of SI 
messages, contents of SI messages, or change in the scheduling of SI messages on BCCH. Changes in the contents of 
the SID message shall not to be reflected in the BCCH_CHANGE_MARK. Changes of the contents of the RACH 
Control Parameters information element alone (see 3GPP TS 44.018) may optionally be reflected in the BCCH- 
CHANGE-MARK ; if reflected, the SI-CHANGE-FIELD parameter may indicate only one of the SI message 
containing the RACH Control Parameters. When the BCCH_CHANGE_MARK is incremented, the 
SI_CHANGE_FIELD parameter shall be set to an appropriate value to indicate the nature of the latest change in the 
BCCH information. 

When PBCCH is not present in the cell, the network may increment the BCCH_CHANGE_MARK value by more than 
one, modulo 8, in order to enforce a complete acquisition of BCCH information of all mobile stations. 

If PBCCH is not present in the cell, instances of the SI 18 and SI 20 message may be broadcast on the BCCH if non- 
GSM broadcast information is transmitted. 

The network indicates the support of the PACKET SI STATUS message in the SI13 message. 

5.5.2.1 .3 System information on PACCH (and other logical channels) 

The network may broadcast PSI and SI messages on PACCH. In particular, if a mobile station is busy in packet transfer 
mode or MAC-Shared state and thus unable to receive the relevant blocks on the broadcast channels (PBCCH or 
BCCH) for a period longer than 15 seconds, the following requirements apply: 

If PBCCH is present in the cell, the network may broadcast the PSIl message on PACCH such that the mobile 
station may receive the PSIl message at least every 15 s. 

If PBCCH is not present in the cell, the network may broadcast the PSI 13 message on PACCH such that the 
mobile station may receive the PSI13 messages at least every 15 s. 

If the network has indicated the use of in-band signalling for a given MBMS radio bearer (with the MBMS In-band 
Signalling Indicator information element included in the MBMS ASSIGNMENT message in the serving cell and/or in 
the MBMS NEIGHBOURING CELL INFORMATION message in the old cell), it shall broadcast the full system 
information on PACCH of that MBMS radio bearer, as described in sub-clause 5.5.2.1.3b. 

Furthermore, the network may broadcast PSI messages on PCCCH. In particular, the network may send the PSIl and 
PSI13 messages on PCCCH to notify mobile stations in packet idle mode or MAC-Idle state about changes in the 
PBCCH information or changes of the PBCCH channel description. 
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If the network supports the PACKET PSI STATUS message and this message is received from a mobile station, the 
network may schedule the missing PSI messages for that mobile station on PACCH (sub-clause 5.5.1.4.3). Optionally, 
the missing PSI messages may be sent in one or more instances of the PACKET SERVING CELL DATA message for 
that mobile station on PACCH. 

If the network supports the PACKET SI STATUS message and this message is received from a mobile station, the 
network may schedule the missing SI messages in one or more instances of the PACKET SERVING CELL DATA 
message for that mobile station on PACCH (sub-clause 5.5.1.4.3), or, in case the mobile station has indicated in the 
PACKET SI STATUS message that it supports the PACKET SERVING CELL SI message, the network should use the 
PACKET SERVING CELL SI messages instead of the PACKET SERVING CELL DATA messages. 

If the network supports the SI2n message, it shall always use the PACKET SERVING CELL SI message when 
broadcasting the SI2n messages on PACCH. 

NOTE: This is required due to the fact that the PACKET SERVING CELL SI is a distribution message making it 
possible for all mobile stations capable of decoding the SI2n message and listening to the PACCH to be 
able to receive the content. 

The network may send the PSI14 message on PACCH to a mobile station in dual transfer mode or MAC-DTM state. 
The scheduling of the PSI14 message is determined by the network. 

If PBCCH is present in the cell and the network changes the contents of any of the PSI messages, it shall set the 
PSI_CHANGED_IND to "1" in all the PSI14 messages it sends in the next 30 seconds. Otherwise, the 
PSI_CHANGED_IND shall be set to "0". 

When a PSI or SI message is received on PACCH during dual transfer mode, no parameters except those relevant for 
monitoring possible changes in the contents of SI or PSI messages (e.g. PBCCH_CHANGE_MARK, 
BCCH_CHANGE_MARK, PSI_CHANGED_IND) shall be applied by the MS for operation in dual transfer mode. 

The network may send neighbour cell PSI and SI messages on PACCH in one or more instances of the PACKET 
NEIGHBOUR CELL DATA message (see sub-clause 8.8.1). 

5.5.2.1 .3a Rules for (P)SI distribution within Packet Serving Cell Data messages 

In order to ensure a consistent distribution and decoding of (P)SI messages contained in PACKET SERVING CELL 
DATA messages, the following rules shall apply: 

Whenever the network starts sending a set of PACKET SERVING CELL DATA message instances in response 
to any PACKET (P)SI STATUS message, the first PACKET SERVING CELL DATA message instance shall be 
started with CONTAINER_INDEX=0. If SIl is broadcast in the serving cell and the MS has requested the SIl 
message, the network shall include the SIl message as the first SI message contained in the set of PACKET 
SERVING CELL DATA messages, starting from the message with CONTAINER_INDEX=0. If the MS is able 
to decode the first SI message contained in the set of PACKET SERVING CELL DATA messages but it was not 
the SIl message, the MS shall conclude that SIl is not broadcast in the serving cell. 

All subsequent instances of a PACKET SERVING CELL DATA message set shall be sent in ascending order of 
CONTAINER_INDEX value. It is allowed to send a PACKET SERVING CELL DATA message with the same 
CONTAINER_INDEX value more than once. 

- Whenever the MS receives a PACKET SERVING CELL DATA message instance with 
CONTAINER_INDEX=0 or with a CONTAINER_INDEX value that is less than the CONTAINER_INDEX 
value of the last received PACKET SERVING CELL DATA message instance, it shall delete any PACKET 
SERVING CELL DATA message instances it may have stored but it shall keep the already extracted PSI/SI 
message instances. 

- Whenever the MS leaves packet transfer mode, it shall delete any PACKET SERVING CELL DATA message 
instances it may have stored but it shall keep the already extracted PSI/SI message instances. 

NOTE : In order to increase the probability that the MS receives the PACKET SERVING CELL DATA message 
instances (especially the one with CONTAINER_INDEX =0), the network may poll the MS with a valid 
RRBP field in the RLC/MAC header of a PACKET SERVING CELL DATA message. Alternatively, the 
network may repeat the PACKET SERVING CELL DATA message instances one or more times. 
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5.5.2.1.3b 



Rules for (P)SI distribution on PACCH of an MBMS radio bearer 



If the network has indicated the use of in-band signalling for a given MBMS radio bearer, it shall broadcast on the 
PACCH the full system information provided on the (P)BCCH: 

In case PBCCH is allocated in the cell, the network shall broadcast the consistent set of PSI messages (it 
broadcasts on PBCCH), on the PACCH/D of the MBMS radio bearer. 

In case PBCCH is not allocated in the cell, the network shall broadcast the consistent set of SI messages (it 
broadcasts on the BCCH), on the PACCH/D of the MBMS radio bearer using PACKET SERVING CELL SI 

messages. 



5.5.2.1.4 



Consistent sets of system information messages 



Certain types of PSI and SI messages are sent on PBCCH and BCCH in a multiple number of instances. If such a PSI or 
SI message type is sent on (P)BCCH, the mobile station shall receive a consistent set of that type of PSI or SI message. 
In some cases, more than one type of PSI messages may be joined into one consistent set, see table 5.5.2.1.4.1. 

Table 5.5.2.1.4.1 : Consistent sets of system information messages 



Consistent set / 
Message Type(s) 


Broadcast 
Channel 


Number of 
instances 


PSI or SI change mark 
parameter 


PSI or SI Index 
parameter 


PSI or SI count 
parameter 


PSI2 


PBCCH 


1 -8 


PSI2 CHANGE MARK 


PSI2 INDEX 


PSI2 COUNT 


PSI3 


PBCCH 


1 


PSI3 CHANGE MARK 






PSI3 bis 


PBCCH 


1 - 16 


PSI3 CHANGE MARK 


PSI3bis INDEX 


PSI3bis COUNT 


PSI3ter 


PBCCH 


0- 16 


PSI3 CHANGE MARK 


PSI3ter INDEX 


PSISter COUNT 


PSI3 quater 


PBCCH 


0-16 


PSI3 CHANGE MARK 


PSI3quater INDEX 


PSI3quater COUNT 


PSI5 


PBCCH 


0-8 


PSI5 CHANGE MARK 


PSI5 INDEX 


PSI5 COUNT 


PSI6 


PBCCH 


0-8 


PSI6 CHANGE MARK 


PSI6 INDEX 


PSI6 COUNT 


PSI7 


PBCCH 


0-8 


PSI7 CHANGE MARK 


PSI7 INDEX 


PSI7 COUNT 


PSI8 


PBCCH 


0-8 


PSI8 CHANGE MARK 


PSI8 INDEX 


PSI8 COUNT 


SI13 

(notes 1 and 2) 


BCCH 


1 


SI13_CHANGE_MARK 






SI2ter 


BCCH 


0-8 


SI2ter MP CHANGE 

MARK and Si2ter 3G 

CHANGE MARK 


SI2ter_INDEX 


SI2ter_C0UNT 


SI2 quater 


BCCH 


0- 16 


BAJND, 3G_BA_IND 

and 
MP CHANGE MARK 


SI2quater_INDEX 


SI2quater_C0UNT 


SI2n 


BCCH 


0-16 


SI2n CHANGE MARK 


SI2n INDEX 


SI2n COUNT 


SI15 


BCCH 


0-4 


DM CHANGE MARK 


SI15 INDEX 


SI15 COUNT 


SI18 


BCCH 


0-8 


SI18 CHANGE MARK 


SI18 INDEX 


None (Note 4) 


S119 


BCCH 


0-8 


SI19 CHANGE MARK 


SI19 INDEX 


None (Note 4) 


SI20 


BCCH 


0-8 


SI20 CHANGE MARK 


SI20 INDEX 


None (Note 4) 


NOTE 1: If theSnS message provides a GPRS mobile allocation, it shall also provide an SI13_CHANGE_MARK. The 
SI13_CHANGE_MARK shall be used if the indirect encoding of the frequency information is applied in a 
packet assignment, referring to the GPRS mobile allocation provided in the SI13 message. There is only one 
instance of the SI13 message. 

NOTE 2: The PSI13 message may be received on PACCH. It provides the same information as SI13, including the 
SI13_CHANGE_MARK. 

NOTE 3: If PSI2 and SI13 change mar/( values need to be distinguished, e.g. during an activation or release of PBCCH, 
the network should assign appropriate values to these parameters. 

NOTE 4: For SI18, SI19 and SI20 messages, there is no counf parameter (see 3GPP TS 44.018). 



A consistent set of system information messages is identified by a PSI or SI change mark parameter included in each 
message in the set. All messages within a consistent set shall have the same value of this parameter. 

The total number of system information messages of a certain type within a consistent set is indicated by a PSI or SI 
count parameter included in each message in the set. The position of a certain message instance within the consistent set 
of system information messages is indicated by a PSI or SI index parameter. 

The PSI or SI count parameter shall have the value N-1, where N is the number of instances of the particular message 
type present in the consistent set. The PSI or SI index parameter shall have a range from zero to N-1. Different instances 
of a particular message type in a consistent set shall have different values of the PSI or SI index parameter. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 47 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

5.5.2.2 Paging 

The network is required to send valid RLC data blocks or RLC/MAC control blocks continuously on all subchannels on 
PCCCH where paging can appear. 

NOTE: If RLC data blocks are sent in the blocks on PCCCH where paging may appear, the network uses the 
coding schemes CS-1 to CS-4, in order to avoid the expiry of the downlink signalling counter for non- 
EGPRS capable mobile stations (see 3GPP TS 45.002). 

5.5.2.3 Network Assisted Cell Change 

A cell that supports GPRS (in A/Gb mode) and/or lu mode shall indicate if CCN is enabled. This shall be indicated on 
BCCH and on PBCCH in the parameter CCN_ACTIVE (see sub-clause 12.24). The network may also send a PACKET 
MEASUREMENT ORDER message with the parameter CCN_ACTIVE set to order an individual mobile station to 
apply the CCN procedures in the serving cell or a PACKET CELL CHANGE ORDER or a PS HANDOVER 
COMMAND message to order an individual mobile station to apply the CCN procedures in the new cell. This 
parameter controls the overall enabling of CCN. The network may also indicate in system information messages sent on 
BCCH and PBCCH and individually in the PACKET MEASUREMENT ORDER or PACKET CELL CHANGE 
ORDER or PS HANDOVER COMMAND messages whether CCN mode shall be entered towards a particular cell (see 
sub-clause 8.8.2). 

The network may also send neighbour cell system information on PACCH to be used by the mobile station at initial 
access after cell re-selection (see sub-clause 8.8.1). 

When the network receives a PACKET CELL CHANGE NOTIFICATION message from the mobile station, the 
network may respond by sending neighbour cell system information for the proposed cell or another cell and also 
complete the transmission of ongoing data packets before sending a PACKET CELL CHANGE CONTINUE message 
(to confirm the proposed cell) or a PACKET CELL CHANGE ORDER message. The neighbour cell information is sent 
in PACKET NEIGHBOUR CELL DATA messages. 

The ARFCN for BCCH and the BSIC identifying a GSM neighbour cell shall be included in the PACKET CELL 
CHANGE CONTINUE message in case a set of PACKET NEIGHBOUR CELL DATA messages referred by the 
corresponding CONTAINERJD value was sent for that cell without ARFCN and BSIC provided. If included by the 
network in the PACKET CELL CHANGE CONTINUE message, ARFCN and BSIC shall reflect the cell proposed in 
the PACKET CELL CHANGE NOTIFICATION message. Upon reception of the PACKET CELL CHANGE 
CONTINUE message the mobile station shall continue the cell reselection in NCO/NCl mode irrespective of the cell 
indicated in the ARFCN and BSIC parameters. 

5.5.2.4 Packet Switched Handover 

If the network supports PS handover it may initiate the PS handover procedure for a mobile station that supports PS 
handover as a result of various trigger conditions such as, but not restricted to, the following: 

- Upon reception of a PACKET CELL CHANGE NOTIFICATION message from a mobile station operating in 
NCO. 

Upon reception of a PACKET CELL CHANGE NOTIFICATION message or measurement reports from a 
mobile station operating in NC 1 . 

Upon reception of measurement reports from a mobile station operating in NC2. 

Upon determining that resource limitations exist for the serving cell. 

Upon receiving the Service UTRAN CCO IE from the SGSN indicating that a mobile station operating in A/Gb 
mode would be better served in a cell supporting a different RAT. 

The NC mode applicable to the new cell shall be indicated by the PS HANDOVER COMMAND message sent to the 
mobile station in the old cell. 
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5.6 Measurement reports 

5.6.0 General 

The network may request measurement reports from the MS. The measurement reporting principles are specified in 
3GPP TS 45.008. The measurement reports consists of 

Network Control (NC) measurement reports sent when the MS is in A/Gb mode and GMM Ready state (see 
3GPP TS 24.008) or the MS is in lu mode and in RRC-Cell_Shared state; this may be performed with either the 
PACKET MEASUREMENT REPORT message or the PACKET ENHANCED MEASUREMENT REPORT 
message. 

5.6.1 Network Control (NC) measurement reporting 

The behaviour of the mobile station is controlled by the parameter NETWORK_CONTROL_ORDER broadcast in the 
PSI5 message on PBCCH, in the SI13 and SI2quater messages on the BCCH and in the PSI13 message on PACCH. 
Alternatively, the network may send the NETWORK_CONTROL_ORDER parameters in a PACKET 
MEASUREMENT ORDER or in a PACKET CELL CHANGE ORDER message on PCCCH or PACCH to a particular 
mobile station or in a PS HANDOVER COMMAND message sent on PACCH to a particular mobile station. The 
parameter NETWORK_CONTROL_ORDER may have one of the values NCO, NCI, NC2 or RESET, see 
3GPP TS 45.008. 

When in mode NCI or NC2, the mobile station shall perform the NC measurements as defined in 3GPP TS 45.008. The 
reporting periods are indicated in the NC_REPORTING_PERIOD_I and NC_REPORTING_PERIOD_T field of the 
PSI5, the SI2quater, the PACKET CELL CHANGE ORDER or the PACKET MEASUREMENT ORDER message. If 
NC_NON_DRX_PERIOD, NC_REPORTING_PERIOD_I or NC_REPORTING_PERIOD_T have not been received 
by the mobile station the default values shall be used. The mobile station shall apply to the timer T3158 either the 
NC_REPORTING_PERIOD_I when in packet idle mode or the NC_REPORTING_PERIOD_T when in packet transfer 
mode. The measurement results shall be sent to the network using the procedures specified in sub-clause 7.3 for packet 
idle mode, and in sub-clause 8.3 for packet transfer mode. 

On expiry of timer T3158, the mobile station shall restart timer T3158 with the indicated reporting period, perform the 

measurements and send either the PACKET MEASUREMENT REPORT message or the 

PACKET ENHANCED MEASUREMENT REPORT to the network. The condition for sending the 

PACKET ENHANCED MEASUREMENT REPORT message instead of the PACKET MEASUREMENT REPORT 

message is based on the REPORT_TYPE parameter and if the MS has received BSIC information for all cells. For the 

detailed conditions see sub-clauses 11.2.23, 11.2.4 and 11.2.9b and also 3GPP TS 44.018 sub-clause 10.5.2.33b. 

A mobile station in mode NC 1 or NC2 may receive a new indicated reporting period while timer T3 158 is active. If the 
new indicated reporting period is less than the time to expiry of timer T3158, the mobile station shall immediately 
restart timer T3158 with the new indicated reporting period. Otherwise, the timer T3158 shall continue to run. 

When changing from packet transfer mode to packet idle mode, a mobile station in mode NCI or NC2 shall restart the 
timer T3158 with the reporting period determined by the NC_REPORTING_PERIOD_I parameter if at least one 
PACKET MEASUREMENT REPORT or PACKET ENHANCED MEASUREMENT REPORT message was sent in 
packet transfer mode. Otherwise the timer T3158 shall continue to run. 

When changing from packet idle mode to packet tranfer mode, a mobile station in mode NCI or NC2 shall restart the 
timer T3158 with the reporting period determined by the NC_REPORTING_PERIOD_T parameter if the reporting 
period is less than the time to expiry of timer T3158. Otherwise the timer T3158 shall continue to run. 

When a mobile station leaves the GMM Ready state, the timer T3158 shall be stopped and no more measurement 
reports shall be sent to the network. 

A mobile station may reselect a new cell or may be ordered to reselect a new cell with mode NCI or NC2 while timer 
T3158 is active. If time to expiry of timer T3158 is greater than the indicated reporting period for the new cell, the 
mobile station shall immediately restart timer T3158 with the indicated reporting period for the new cell. Otherwise, the 
timer T3158 shall continue to run. 
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At cell reselection the NC measurement parameters valid for the mobile station in the new cell 
(NETWORK_CONTROL_ORDER, NC_NON_DRX_PERIOD, NC_REPORTING_PERIOD_I and 
NC_REPORTING_PERIOD_T) are either: 

brought from the old cell if received in a PACKET CELL CHANGE ORDER message sent in the old cell; or 

received in a broadcast PSI5, SI13, PSI13 or SI2quater message in the new cell. If no parameters have been 
brought from the old cell, and until individual measurement parameters are received in the new cell, the mobile 
station shall use the broadcast measurement parameters from PSI5 if a PBCCH is allocated in the cell or 
SI2quater if a PBCCH is not allocated in the cell or use the default parameter values. 

The default frequency list to be applied in the new cell following a cell reselection or the successful completion of the 
PS handover procedure shall be the BA(GPRS) list of that cell until a new PACKET MEASUREMENT ORDER 
message is received. For the case of cell reselection the BA(GPRS) list could also have been modified by frequency 
parameters received in a PACKET_CELL_CHANGE_ORDER message in the old cell. 

For (NC) measurements reporting, the Mobile Station shall use PACKET ENHANCED MEASUREMENT REPORT 
messages instead of PACKET MEASUREMENT REPORT messages if that is indicated by the parameter 
REPORT_TYPE and if at least one BSIC is allocated to each frequency in the B A(GPRS) list. 

For a multi-RAT mobile station, reports on 3G cells may also be included in the reporting. For report with the 
PACKET MEASUREMENT REPORT message, reporting is performed on two separate lists: the BA(GPRS) and the 
3G Neighbour Cell List (for a multi-RAT MS). For report with the 

PACKET ENHANCED MEASUREMENT REPORT message, reporting is performed on the Neighbour Cell List 
(defined in sub-clause 5.6.3.3). 

A mobile station involved in an RR connection (in class A mode of operation), shall not send Network Control 
measurement reports to the network during that period. The mobile station shall return to the previous reporting mode 
when the RR connection is released. 

5.6.2 (void) 

5.6.3 Additional measurement and reporting parameters 

Some parameters from the PACKET MEASUREMENT ORDER, PACKET CELL CHANGE ORDER, SI2quater, 
PSBbis, PSBter, PSBquater or PSI5 messages allow to build GPRS Measurement Parameters, GPRS 3G Measurement 
Parameters and neighbour cell lists which are used for Network Control (NC) measurement reporting. 

5.6.3.1 Deriving the 3G Neighbour Cell list from the 3G Neighbour Cell description 

In a cell without a PBCCH allocated, the 3G Neighbour Cell list is given by one or more instances of the SI2quater 
message with the same 3G_BA_IND value. 

In a cell with a PBCCH allocated, the 3G Neighbour Cell list is given by one or more instances of the PSBquater 
message with the same PSI3_CHANGE_MARK value. 

The 3G Neighbour cell list may be modified by a PACKET CELL CHANGE ORDER message (in which case the 
reference list is given on the new cell) or by one or more instances of the PACKET MEASUREMENT ORDER 
message with the same 3G_BA_IND value or PSI3_CHANGE_MARK value. 

The 3G Neighbour Cell list may contain up to 96 3G Neighbour Cells and/or UTRAN frequencies for RSSI reporting. 

Each 3G Neighbour Cell Description received is added to the 3G Neighbour Cell list, starting with the index equal to 
the parameter Index_Start_3G. If this parameter is not present then the value shall be used. 

For each 3G Neighbour Cell Description received, the cells / UTRAN frequencies are indexed in the following order: 

1: UTRAN FDD cells / UTRAN FDD frequencies: FDD UARFCNs are indexed in the order of occurrence in the 
3G Neighbour Cell description. For each FDD UARFCN indicating UTRAN FDD cells, the cells are indexed in 
the order of increasing values of the decoded FDD_CELL_INFORMATION parameters. 
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2: UTRAN TDD cells / UTRAN TDD frequencies: TDD UARFCNs are indexed in the order of occurrence in the 
3G Neighbour Cell description. For each TDD UARFCN indicating UTRAN TDD cells, the cells are indexed in 
the order of increasing values of the decoded TDD_CELL_INFORMATION parameters. 

If more than one cell / UTRAN frequency with the same index in the 3G Neighbour Cell list are provided by different 
instances of 3G Neighbour Cell descriptions, the cell / UTRAN frequency from the message instance with the highest 
index shall be used. In case the same 3G Cell / UTRAN frequency occurs more than once in the resulting 3G Neighbour 
Cell list, each occurrence shall be assigned an index but only the cell / UTRAN frequency with the highest index in the 
3G Neighbour Cell list shall be referred to in measurement reports. 

The 3G Neighbour Cell Description may contain information on 3G Neighbour Cells / UTRAN frequencies to be 
removed (REM0VED_3GCELL_Description). The cells / UTRAN frequencies to be removed are identified by their 
indices in the 3G Neighbour Cell list. Removed cells / UTRAN frequencies shall keep their indices but no measurement 
shall be performed. If the index is higher than 95 or points to a 3G cell / UTRAN frequency that does not exist, this 
shall not be considered as an error. 

In a cell without PBCCH allocated, the mobile station shall only combine 3G Neighbour cells / UTRAN frequencies 
from SI2quater messages indicating the same value of the 3G_B A_IND without any message indicating a different 
value of the 3G_B A_IND received in between. 

In a cell with a PBCCH allocated, the mobile station shall only combine 3G Neighbour cells / UTRAN frequencies 
from PSBquater messages indicating the same PSI3_CHANGE_MARK value. 

If a 3G Neighbour Cell Description includes non-supported frequencies or Radio Access Technologies or if the same 
cell / UTRAN frequency occurs more than once, this shall not be considered as an error; indices in the 3G neighbour 
Cell list shall be incremented accordingly. If a cell / UTRAN frequency is provided for an index higher than 95 in the 
3G Neighbour Cell list, this shall not be considered as an error; the cell / UTRAN frequency shall not be included in the 
3G Neighbour Cell Hst. 

The MS behaviour is not specified if the number of 3G frequencies or cells exceeds the MS monitoring capabilities as 
defined in 3GPP TS 45.008. 

5.6.3.2 Deriving BA(GPRS) and the GSM Neighbour Cell list 

In a cell without a PBCCH allocated, BA(GPRS) is equal to the BA (list) from the SI2/SI2bis/SI2ter messages. BSICs 
from the GPRS BSIC Description from one or more instances of the SI2quater message (if broadcast) shall be 
associated with BA(GPRS) with the same BA_IND value to create the GSM Neighbour Cell list, as described in 
3GPP TS 44.018 (sub-clause 3.4.1.2.1.2). If GPRS BSIC Description is not broadcast, the GSM Neighbour Cell list is 
equal to BA(GPRS) (only a frequency list). 

In a cell with a PBCCH allocated, BA(GPRS) is derived from the neighbour cell parameters sent in PSI3 and ascending 
order of PSBbis on PBCCH with the same PSI3_CHANGE_MARK value (see sub-clause 11. 2.20). Each neighbour 
cell listed in PSI3 and in one or more instances of PSBbis is assigned an ascending index used for measurement reports. 
The first neighbour cell in PSB has the lowest index (= 0), and the last neighbour cell in the highest indexed PSBbis 
message has the highest index. The GSM Neighbour Cell list is equal to BA(GPRS). 

The GSM Neighbour Cell list may contain up to 96 GSM Neighbour Cells. The total number of frequencies to measure 
shall not exceed 32. If the list includes more than 32 frequencies, the MS shall only measure the 32 frequencies with the 
lowest indices. 

The GSM Neighbour Cell list may be modified by "NC Frequency List" in a PACKET CELL CHANGE ORDER 
message (in which case the reference list is given on the new cell) or one or more instances of the PACKET 
MEASUREMENT ORDER message with the same BA_IND value or PSI3_CHANGE_MARK value. 

The "NC Frequency List" may add cells to the GSM Neighbour Cell list (see sub-clauses 11. 2. 4 and 1 1.2.9b). These 
cells shall be added at the end of the GSM Neighbour Cell list and indexed in the order of occurrence within the 
PACKET CELL CHANGE ORDER message or ascending instances of the PACKET MEASUREMENT ORDER 
message. The list of added cells may contain GPRS and optionally lu mode cell re-selection parameters. The "NC 
Frequency List" does not impact the serving cell parameters. 

The "NC lu Mode Only Capable Cell List" may add cells to the GSM Neighbour Cell Hst (see sub-clauses 11.2.4 and 
1 1 .2.9b). These lu mode only capable cells shall be added at the end of the GSM Neighbour Cell list after A/Gb mode or 
both A/Gb and lu mode capable cells and indexed in the order of occurrence within the PACKET CELL CHANGE 
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ORDER message or ascending instances of the PACKET MEASUREMENT ORDER message. The list of added cells 
may contain lu mode only cell re-selection parameters. 

In case the same cell (ARFCN+BSIC) or the same ARFCN without BSIC occur more than once in the resulting GSM 
Neighbour Cell list, each occurrence shall be assigned an index but only the cell with the highest index shall be used for 
cell re-selection and referred to in measurement reports. 

The "NC Frequency List" may delete frequencies from the BA(GPRS) list (see sub-clause 1 1.2.9b). The frequencies to 
be removed are identified by their indices in the BA(GPRS). In this case all cells associated with the removed 
frequencies shall be removed from the GSM Neighbour Cell list. Removed cells/frequencies shall keep their indices but 
no measurements or reporting shall be performed. If the index points to a cell that does not exist, this shall not be 
considered as an error. 

If the mobile station receives a PACKET MEASUREMENT ORDER message (full set of instances) with changed 
PMO_IND parameter value, any old "NC frequency list" shall be deleted. If the last PACKET MEASUREMENT 
ORDER message (full set of instances) does not contain a "NC frequency list" (no added or deleted frequencies) the 
mobile station shall return to BA(GPRS). 

In a cell without PBCCH allocated, if the BA_IND parameter is changed, the mobile station shall re-read and rebuild 
the GSM Neighbour Cell list. 

In a cell with a PBCCH allocated, if PSI3_CHANGE_MARK is changed, the mobile station shall re-read and rebuild 
the GSM Neighbour Cell list. 

5.6.3.3 Deriving the Neighbour Cell list from the GSM Neighbour Cell list and the 3G 
Neighbour Cell list 

The Neighbour Cell list may contain up to 96 Neighbour Cells. For report with the 

PACKET ENHANCED MEASUREMENT REPORT message, the Neighbour Cell list is the concatenation of the GSM 
Neighbour Cell list and the 3G Neighbour Cell list (if any). In this concatenation the value of the parameter 
Absolute_Index_Start_EMR is added to the 3G Neighbour Cell list indices. If the same index occurs for a GSM Cell 
and a 3G Cell, the GSM Cell shall be used. 

NOTE: For report with the PACKET MEASUREMENT REPORT message, the concatenated list is not used. 
Instead, the two lists are used separately, as defined in table 11. 2. 9. 2 from sub-clause 11. 2. 9. 

5.6.3.4 GPRS Real Time Differences 

The GPRS Real Time Difference list may contain up to 96 Real Time Difference parameters. 

In a cell without PBCCH allocated, GPRS Real Time Difference information may be received from the SI2quater 
message and associated with the BA (list) from the SI2/SI2bis/SI2ter messages with the same BA_IND value, see 
3GPP TS. Each frequency in the BA (list) may be associated to 0, 1 or more Real Time Difference parameters. The 
Real Time Difference parameters may be received before the corresponding BA (list). The parameter 
B A_Index_Start_RTD in each structure indicates the index of the frequency in the B A (list) to be taken as a starting 
reference. A sub-structure is included for each frequency referenced. Each of those sub-structures indicates if 0, 1 or 
more RTD parameters are present for this frequency. If a frequency in the B A (list) is not provided with Real Time 
Difference information by any of the message instances with correct B A_IND value, it shall be assumed that no 
information is available for that frequency. If the MP_CHANGE_MARK parameter is changed, the mobile station shall 
re-read the Real Time Difference parameters. 
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In a cell with a PBCCH allocated, GPRS Real Time Difference information may be received from the PSBter messages 
and associated with the GSM Neighbour Cell Ust with the same PSI3_CHANGE_MARK value. In this case each cell 
may be associated to or 1 Real Time Difference parameter. The Real Time Difference parameters may be received 
before the corresponding GSM Neighbour Cell list. The parameter Cell_Index_Start_RTD in each structure indicates 
the index of the cell in the GSM Neighbour Cell list to be taken as a starting reference. A sub-structure is included for 
each GSM Neighbour Cell referenced. Each of those sub-structures indicate if or I RTD parameter is present for this 
GSM Neighbour Cell. If a cell in the GSM Neighbour Cell list is not provided with Real Time Difference information 
by any of the message instances with correct PSI3_CHANGE_MARK value, it shall be assumed that no information is 
available for that cell. If some Real Time Difference information are provided for a cell that does not exist, this shall not 
be considered as an error. See sub-clause 11.2.21. 

5.6.3.5 GPRS Report Priority Descriptions 

In a cell without PBCCH allocated. Report Priority information may be received from the SYSTEM INFORMATION 
TYPE 2 QUATER message and associated to the Neighbour Cell list with the same BA_IND value and 3G_BA_IND 
value, see 3GPP TS 44.018. If the parameter MP_CHANGE_MARK is changed, the mobile shall re-read the GPRS 
Report Priority information. Each REP_PRJORITY bit of this field relates to indices of the Neighbour Cell list starting 
with index 0. 

In a cell with a PBCCH allocated. Report Priority information for GSM cells may be received from the PACKET 
SYSTEM INFORMATION TYPE 3 TER message and associated to the GSM Neighbour Cell list with the same 
PSI3_CHANGE_MARK value, see sub-clause 11.2.21a. Each REP_PRIORITY bit of this field relates to indices of the 
GSM Neighbour Cell list starting with index 0. 

In a cell with a PBCCH allocated. Report Priority information for 3G cells may be received from the PACKET 
SYSTEM INFORMATION TYPE 3 QUATER message and associated to the 3G Neighbour Cell list with the same 
PSI3_CHANGE_MARK value, see sub-clause 1 1 .2.21b. Each REP_PRIORITY bit of this field relates to indices of the 
3G Neighbour Cell list starting with index 0. 

If Report Priority information is received as part of a PACKET MEASUREMENT ORDER or PACKET CELL 
CHANGE ORDER message, it is associated to the Neighbour Cell list and may be received before the corresponding 
Neighbour Cell list. Each REP_PRIORITY bit of this field relates to indices of the Neighbour cell list, starting with 
index 0. 

Indices exceeding the value 95 shall be ignored. If there are fewer indices than the number of Neighbour Cells, the 
value shall be assumed for the missing bits. 

5.6.3.6 GPRS Measurement Parameters and GPRS 3G Measurement Parameters 

In a cell without a PBCCH allocated, GPRS Measurement Parameters and GPRS 3G Measurement Parameters may be 
received from SI2quater message, see 3GPP TS 44.018. When the parameter MP_CHANGE_MARK is changed, the 
mobile station shall re-read GPRS Measurement Parameters and GPRS 3G Measurement Parameters. 

In a cell with a PBCCH allocated, GPRS Measurement Parameters and GPRS 3G Measurement Parameters may be 
received from PSBquater and PSI5 messages, see sub-clauses 1 1 .2.21b and 1 1 .2.23. When the PSI3_CHANGE_MARK 
or PSI5_CHANGE_MARK parameter is changed, the MS shall re-read the corresponding Measurement Parameters and 
3G Measurement Parameters. 

If different values are received for the same parameter in different instances of a message, only the value in the instance 
with the highest index shall be used. 

5.6.3.7 The GPRS 3G Cell Reselection list 

This sub-clause applies only to a (3G) multi-RAT MS. 

In a cell without a PBCCH allocated, the GPRS 3G Cell Reselection Hst is equal to the 3G Cell Reselection Hst that is 
defined in 3GPP TS 44.018. 

In a cell with a PBCCH allocated, the GPRS 3G Cell Reselection list is the union of 3G Cells and/or 3G frequencies 
provided in one or more instances of the PSBquater message. The GPRS 3G Cell Reselection list may contain up to 96 
3G Cells. 3G Cells not provided explicitly in the PSBquater message (frequencies on their own) are not included in 
these 96 cells. Up to 8 frequencies on their own can be added to these 96 cells. 
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The MS behaviour is not specified if the number of 3G frequencies or cells exceeds the MS monitoring capabilities as 
defined in 3GPP TS 45.008. 

5.6.4 Measurement reporting in broadcast/multicast receive mode 

The mobile station in broadcast/multicast receive mode shall report neighbouring cell measurements when polled for an 
MBMS DOWNLINK ACK/NACK message according to the procedures specified in sub-clause 8.1.4.2. Measurement 
reporting in broadcast/multicast receive mode shall not affect the procedure for NC measurement reporting defined in 
sub-clause 5.6.1. 

For reporting neighbouring cells in the MBMS Neighbouring Cell Report struct, the following rules apply: 

the neighbouring cells shall belong to the six strongest non-serving and allowed (see 3GPP TS 45.008) carriers 

the cells for which cell reselection parameters have been acquired, shall be reported in decreasing order of the 
corresponding cell re-selection ranking (see 3GPP TS 45.008), i.e. the highest ranked first. 

the neighbouring cells for which cell reselection parameters have not been acquired, shall be reported in 
decreasing order of the received signal level average (see 3GPP TS 45.008), i.e. the neighbouring cell with 
highest received signal average first. 

in case there are cells for which cell reselection parameters have and cells for which cell reselection parameters 
have not been acquired to be included in the MBMS Neighbouring Cell Report struct, the cells shall be reported 
in alternating order, starting with the highest ranked cell for which cell reselection parameters have been 
acquired. 

the MBMS Neighbouring Cell Report struct shall include as many cells as possible but shall not exceed 6 cells. 

EXAMPLE: there is space to report 4 neighbouring cells in the MBMS DOWNLINK ACK/NACK message. 

In this case, the neighbouring cells in the MBMS Neighbouring Cell Report stuct shall be reported 
in the following order : 

y(l), n(l), y(2), y(3), cells y(4) and y(5) are not reported, 

where 

y(l) is the highest ranked cell for which cell reselection parameters have been acquired 
y(2) is the 2""* highest ranked cell for which cell reselection parameters have been acquired 
y(3) is the 3"* highest ranked cell for which cell reselection parameters have been acquired 
y(4) is the 4* highest ranked cell for which cell reselection parameters have been acquired 
y(5) is the 5* highest ranked cell for which cell reselection parameters have been acquired 
n(l) is the highest ranked (and the only one within the 6 strongest) cell for which cell reselection 
parameters have not been acquired 

If cell re-selection is triggered towards a neighbouring cell (see 3GPP TS 45.008), the mobile station shall indicate this 
to the network with the RESEL_CRITERIA_FULFILLED parameter when reporting measurement results for that cell. 
In this case, the mobile station shall not include any other measurement results for any other neighbouring cell in the 
MBMS Neighbouring Cell Report struct. 

When reporting measurement results for a neighbouring cell, the mobile station shall indicate with the 
RESEL_PARAMS_ACQUIRED parameter whether it has acquired the reselection parameters for that cell. The mobile 
station shall also indicate whether it has received (as described in sub-clause 7.7.3) the MBMS bearer parameters in that 
cell for the MBMS session acknowledged in the MBMS DOWNLINK ACK/NACK message. If so the mobile station 
shall indicate the latest corresponding (i.e. for that cell and that session) MBMS_PTM_CHANGE_MARK parameter 
received. The network may use this information to schedule MBMS NEIGHBOURING CELL INFORMATION 
messages accordingly. If for a given session the network has received from a mobile station an indication that no 
MBMS bearer parameters for that session in a neighbouring cell have been received, the network may establish that 
session in that neighbouring cell, if not already established provided that that cell supports MBMS and belongs to the 
MBMS service area. 
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5.7 Dual transfer mode enhancements 

The mobile station and the network may support enhanced DTM CS estabhshment and enhanced DTM CS release 
procedures, called DTM enhancements. 

By using enhanced DTM CS establishment procedure, an RR connection can be initiated by either the mobile station or 
the network while the mobile station is in packet transfer mode. The procedure is specified in sub-clause 8.9. 

By using enhanced DTM CS release, the network may delay the release of the RR connection until the mobile station in 
dual transfer mode has received the required system information, in order to maintain the radio resources (PDCH(s)) 
after the release of the RR connection while in dual transfer mode, as specified in sub-clause 5.5.1.1b.5. 

The support of the DTM enhancements is optional for the mobile station and the network and is indicated in the Mobile 
Station Classmark 3 IE, the MS Radio Access Capability IE and the GPRS Cell Options IE. A mobile station supporting 
the DTM enhancements shall also support the extended RLC/MAC control message segmentation as defined in 9.1.12a. 
The DTM enhancements shall be used if the mobile station and the network support them. 



Paging procedures 



For a mobile station in packet idle mode, the network may use the paging procedures to initiate the establishment of an 
RR connection, to trigger a cell update from the mobile station prior to a downlink packet transfer, or to send MBMS 
notification. A number of mobile stations can be paged for either downlink packet transfer or RR connection 
establishment in the same paging message. 

For a mobile station in packet transfer mode, the network may use the paging procedures to initiate the establishment of 
an RR connection. A number of mobile stations can be paged for RR connection establishment in the same paging 
message. After sending the mobile station a PS HANDOVER COMMAND message the network shall not use paging 
procedures to initiate the establishment of an RR connection for that mobile station until the PS handover procedure has 
been completed (see sub-clause 8.10). 

Paging procedures for RR connection establishment are described in sub-clause 6.1. Paging procedures for downlink 
packet transfer are described in sub-clause 6.2. 

6.1 Paging procedure for RR connection establishment 

The network may initiate the establishment of an RR connection by the paging procedure for RR connection 
establishment. 

The network initiates the paging procedure for RR connection establishment by sending a paging request message on 
the appropriate paging subchannel on CCCH or PCCCH, addressing the mobile station and indicating RR connection 
establishment. 

The paging subchannels on CCCH and PCCCH are specified in 3GPP TS 45.002 and 3GPP TS 43.013. The paging 
request message for RR connection establishment is sent on the PCCCH if the mobile station is GPRS attached, 
PCCCH is present in the cell and the network operates in network mode of operation I (see 3GPP TS 23.060). 
Otherwise, the paging request message is sent on CCCH. 

The network may also page the mobile station for RR connection establishment by sending a paging request message on 
PACCH if the mobile station is in packet transfer mode. 

A mobile station in packet transfer mode is not required to decode the paging subchannels, on neither CCCH nor 
PCCCH, in the following two cases: 

the mobile station is not capable to handle an RR connection and a TBF simultaneously (GPRS class B mode of 
operation); or 

the mobile station requires that the BSS co-ordinates the allocation of radio resources for an RR connection and 
one or more simultaneous TBFs (GPRS class A mode of operation by means of DTM). 
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6.1 .1 Paging initiation using paging subclnannel on CCCH 

The paging initiation procedure and the paging request messages used on CCCH are specified in 3GPP TS 44.018. 

6.1 .2 Paging initiation using paging subclnannel on PCCCH 

The network initiates the paging procedure by sending a PACKET PAGING REQUEST message on an appropriate 
paging subchannel on PCCCH, considering the DRX parameters valid for each targeted mobile station. 

For each mobile station, that is paged for RR connection establishment, a channel needed field is included in the 
PACKET PAGING REQUEST message, see sub-clause 11.2.10. The channel needed field defines how the mobile 
stations shall use the establishment cause field in the CHANNEL REQUEST message, as specified in 3GPP TS 44.018. 

6.1 .3 Paging initiation using PACCH 

Paging initiation using PACCH applies when sending a paging request message to a mobile station that is GPRS 
attached, when the mobile station is in packet transfer mode or in broadcast/multicast receive mode, if so indicated for 
that mobile station by the network, and the network is able to co-ordinate the paging request with the radio resources 
allocated for the mobile station (or MBMS session) on a PDCH. 

This kind of paging co-ordination shall be provided in network mode of operation I (see 3GPP TS 23.060). A mobile 
station in packet transfer mode in a cell indicating support of network mode of operation I in the NMO field broadcast 
on BCCH or PBCCH shall expect the paging messages to be received on the PACCH. 

This kind of paging co-ordination shall be provided for mobile stations capable of DTM if the network supports DTM. 
A mobile station capable of DTM in packet transfer mode in a cell indicating support of DTM procedures in the 
DTM_SUPPORT field broadcast on BCCH or PBCCH shall expect the paging messages to be received on the PACCH. 

This kind of paging co-ordination may be provided also in network mode of operation 11 or 111 regardless of the DTM 
capability of the cell and of the mobile station and shall be indicated in that case by setting the 
BSS_PAGING_COORDINATION field to "The cell supports Circuit-Switched paging coordination" on BCCH or 
PBCCH. If such indication is received, a mobile station in packet transfer mode shall expect the paging messages to be 
received on the PACCH. 

A mobile station in broadcast/multicast receive mode shall expect the paging messages to be received on the PACCH of 
an MBMS radio bearer if the network has indicated so with the MBMS In-band Signalling Indicator field in the MBMS 
ASSIGNMENT and/or MBMS NEIGHBOURING CELL INFORMATION messages, and if the mobile station has an 
MS_ID on that MBMS radio bearer. 

The network shall not send paging messages on the PACCH to a mobile station whose MS_ID has been released 
because the mobile station has not responded when being polled (i.e. T3195 has started for that MS_ID). 

a) If a mobile station is receiving multiple MBMS radio bearers and the mobile station has an MS_ID on at least one of 
the MBMS radio bearers where the network has indicated that system information for the serving cell and paging 
messages are sent on the PACCH/D then the mobile station shall not monitor its paging group on the (P)CCCH in 
parallel to the MBMS radio bearers. 

The network shall send the PACKET PAGING REQUEST message to the mobile station on the appropriate PACCH. 
The message includes the mobile station identification and the channel needed field which defines how the mobile 
station shall use the estabUshment cause field in the CHANNEL REQUEST message, as specified in 3GPP TS 44.018. 

6.1.4 Paging response 

Upon receipt of a Paging Request or Packet Paging Request message, for the purpose of triggering an RR connection 
establishment, a mobile station operating in GPRS class B mode of operation and in packet transfer mode shall either 
ignore or respond to the paging request according to 3GPP TS 22.060. 

When the mobile station responds to a paging request for RR connection establishment, it shall follow the paging 
response procedures as specified in 3GPP TS 44.018. For that purpose, a mobile station in packet transfer mode or a 
mobile station that has initiated a packet access procedure may abort all ongoing TBFs or the packet access procedure in 
the following two cases: 
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the mobile station is not capable to handle an RR connection and a TBF simultaneously (GPRS class B mode of 
operation); or 

the mobile station requires that the ESS co-ordinates the allocation of radio resources for an RR connection and 
one or more simultaneous TBFs (GPRS class A mode of operation by means of DTM). 

6.2 Paging procedure for downlink packet transfer 

The network may initiate the paging procedure for downlink packet transfer in order to obtain the mobile station cell 
location required for the downlink packet transfer. The procedure is triggered by a page request from the GMM 
sublayer on the network side, see 3GPP TS 24.007 and 3GPP TS 44.018. The procedure is initiated by sending a paging 
request message on the appropriate paging subchannel on CCCH or PCCCH. The paging subchannels on CCCH and 
PCCCH are specified in 3GPP TS 45.002 and 3GPP TS 43.013. 

The paging request message is sent on PCCCH, if PCCCH is present in the cell. Otherwise, the paging request message 
is sent on CCCH. 

A mobile station that indicates DTM support to the network is not required to decode the paging subchannels, on 
neither CCCH nor PCCCH, while it is in dedicated mode. If the cell location for a mobile station that has indicated 
DTM support is required while the mobile station is in dedicated mode, the network may use the packet notification 
procedure defined in 3GPP TS 44.018. 

6.2.1 Paging procedure using paging subcinannei on CCCH 

The packet paging procedure and the paging request messages used on CCCH are specified in 3GPP TS 44.018. 

6.2.2 Paging using paging subcinannei on PCCCH 

The network initiates the paging procedure by sending a PACKET PAGING REQUEST message on an appropriate 
paging subchannel on PPCH, considering the DRX parameters valid for each targeted mobile station. 

6.2.3 Paging response 

On receipt of a PACKET PAGING REQUEST message, the RR sublayer of addressed mobile station indicates the 
receipt the paging request to the GMM sublayer (see 3GPP TS 24.007 and 3GPP TS 44.018). 

NOTE: The mobile station performs a pageresponse by sending an upper layer PDU to the network as defined in 
3GPP TS 44.018 and 3GPP TS 44.064. The transfer of an upper layer PDU may serve as a cell update. 

6.3 Paging Procedures for MBMS Notification 

6.3.1 Notification to mobile station in packet idle mode 
6.3.1.1 General 

The paging procedure for MBMS notification of an MBMS session is initiated by the reception of an MBMS SESSION 
START REQUEST message from the SGSN for this session, see 3GPP TS 48.018. The MBMS notification may be 
repeated during the session. 

The network initiates the paging procedure for MBMS notification on PCCCH (sub-clause 6.3.1.3) if PCCCH is present 
in the cell, otherwise on CCCH (sub-clause 6.3.1.2). The paging procedure for MBMS notification is also initiated on 
PACCH when the mobile station is in broadcast/multicast receive mode, if so indicated for that mobile station by the 
network (sub-clause 6.3.1.3a). 

The paging procedure for MBMS notification consists of the following steps: 

optionally, the pre-notification of the MBMS session; and 

the notification of the MBMS session. 
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A mobile station in broadcast/multicast receive mode shall remain in broadcast/multicast receive mode if a paging 
procedure for a new MBMS session is not completed for any reason. 

6.3.1 .2 Paging procedure for MBMS notification using paging subcinannel 
on CCCH 

The paging procedure for MBMS notification and the paging request messages used on CCCH are specified in 
3GPPTS 44.018. 

6.3.1 .3 Paging procedure for MBMS notification using paging subcinannel 
on PCCCH 

6.3.1.3.1 General 

The network initiates the paging procedure for MBMS notification of an MBMS session by sending a PACKET 
PAGING REQUEST message including for that session either the MBMS pre-notification (see sub-clause 6.3.1.3.2) or 
MBMS notification (see sub-clause 6.3.1.3.3) on one or more paging subchannels on PCCCH. The PACKET PAGING 
REQUEST message may also contain other MBMS (pre)notification(s) and/or pages as described in sub-clauses 6.1.2 
and 6.2.2. The following requirements apply: 

If in the PACKET PAGING REQUEST message the mobile station is at the same time (pre)notified (see sub- 
clauses 6.3.1.3.2 and 6.3.1.3.3) and paged, the mobile station shall discard all (pre)notification(s) in that message 
and proceed as described in sub-clause 6.1 or 6.2, whichever applies. 

If in the PACKET PAGING REQUEST message the mobile station is at the same time pre-notified (see sub- 
clause 6.3.1.3.2) and notified (see sub-clause 6.3.1.3.3), the mobile station shall discard all pre-notifications in 
that message and proceed as described in sub-clause 6.3.1.3.3. 

6.3.1.3.2 MBMS pre-notification 

In order to pre-notify an MBMS session, the network shall send a PACKET PAGING REQUEST message by including 
for that session only the TMGI and, if available, the MBMS Session Identity of that session as contained in the MBMS 
SESSION START REQUEST message. 

Upon reception of a PACKET PAGING REQUEST message including for an MBMS session only the TMGI and, if 
available, the MBMS Session Identity of that session, and if the mobile station requires reception of that 
session, the mobile station shall consider that session as being pre-notified (i.e. the mobile station is pre- 
notified). If the mobile station determines several pre-notified sessions in this message, the mobile station 
shall discard all pre-notifications but the pre-notification for the highest priority session. The mobile 
station in packet idle mode or MAC-Idle state shall then enter non-DRX mode, start timer T3220 and 
proceed as described in sub-clause 6.3.1.3.3. NOTE: In case all pre-notified sessions have the same 
priority, the selection of the highest priority session is implementation-dependent 

While timer T3220 is running, the mobile station shall stop timer T3220 and discard the pre-notification if: 

Any other procedure on PCCCH not related to MBMS is triggered. The mobile station shall then proceed as per 
that procedure. 

A notification is received for a higher priority session. The mobile station shall then proceed as described in sub- 
clause 6.3.1.3.3 

If while timer T3220 is running the mobile station receives a pre-notification for a higher priority session, the 

mobile station shall discard the pre-notification for the lower priority session, remain in non-DRX mode, restart 
timer T3220 and proceed as described in sub-clause 6.3.1.3.3. 

Upon expiry of timer T3220, the mobile station in packet idle mode or MAC-Idle state shall return to DRX mode and 
discard the pre-notification. The mobile station in broadcast/multicast receive mode shall discard the pre-notification 
and remain in broadcast/multicast receive mode. 

A mobile station in broadcast/multicast receive mode that is receiving an MBMS session shall ignore repeated pre- 
notifications of that session. 
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6.3.1.3.3 MBMS notification 

In order to notify an MBMS session, the network shall send a PACKET PAGING REQUEST message by including for 
that session: 

- the TMGI and, if available, the MBMS Session Identity of that session; 

an indication whether counting shall be performed or not; 

optionally the MBMS p-t-m channel description allocated to that session and the estimated duration of the 
MBMS session or, if the MBMS session is ongoing, the estimated remaining duration of the MBMS session; 

- optionally the MPRACH description. 

NOTE 1 : If the MBMS Session Repetition Number IE is included in the MBMS SESSION START REQUEST 
message (see 3GPP TS 48.018), the value part of this IE may be used by the network for e.g. deciding 
whether or not to perform the counting procedure or, in conjunction with the values of 
Allocation/Retention Priority IE (see 3GPP TS 48.018), whether or not to estabUsh an MBMS radio 
bearer for the session. 

Upon reception of a PACKET PAGING REQUEST message including the notification of an MBMS session and if the 
mobile station requires reception of this session, the mobile station shall consider that session as being notified (i.e. the 
mobile station is notified). If the mobile station determines several notified sessions in this message, the mobile station 
shall act upon the notification for the highest priority session. The mobile station shall then stop timer T3220, if 
running, and proceed as described in sub-clause 6.3.1.4. 

NOTE 2: In case all notified sessions have the same priority, the selection of the highest priority session is 
implementation-dependent. 

NOTE 3: Depending on its capabilities, the MS may act upon the notification for lower priority MBMS sessions 
provided it does not affect any of the following procedures for the highest priority MBMS session: 
response to MBMS notification (see sub-clause 6.3.1.4), establishment of MBMS bearer upon receipt of 
MBMS ASSIGNMENT (see sub-clause 7.7.2.2), MBMS packet access procedure (see sub-clause 7.7.1). 

A mobile station in broadcast/multicast receive mode that is receiving an MBMS session shall ignore repeated 
notifications of that session. 

6.3.1.3a Paging procedure for MBMS notification using PACCH 

A mobile station in broadcast/multicast receive mode shall expect the paging messages to be received on the PACCH of 
an MBMS radio bearer if the network has indicated so with the MBMS In-band Signalling Indicator field in the MBMS 
ASSIGNMENT and/or MBMS NEIGHBOURING CELL INFORMATION messages, and if the mobile station has an 
MS_ID on that MBMS radio bearer. 

Under the above circumstances, the network initiates the paging procedure for MBMS notification of an MBMS session 
not only on PCCCH (see sub-clause 6.3.1.3) if PCCCH is present in the cell, otherwise on CCCH (see sub-clause 
6.3.1.2), but also by sending a PACKET PAGING REQUEST message including for that session either the MBMS pre- 
notification (see sub-clause 6.3.1.3.2) or MBMS notification (see sub-clause 6.3.1.3.3) on the appropriate PACCH. The 
PACKET PAGING REQUEST message may also contain other MBMS (pre-)notification(s) and/or pages as described 
in sub-clauses 6.1.2 and 6.2.2 (see sub-clause 6.3.1.3.1). 

The network shall not send paging messages on the PACCH to a mobile station whose MS_ID has been released 
because the mobile station has not responded when being polled (i.e. T3195 has started for that MS_ID). 

Upon reception of MBMS notification on PACCH, the mobile station in broadcast/multicast receive mode shall act 
according to sub-clause 8.1.5.2. 

If the mobile station responds to the MBMS notification: 

it shall act as described in sub-clause 6.3. 1 .4 if PCCCH is present in the cell; 

- otherwise it shall act as described in 3GPP TS 44.018 (sub-clause 3.5.1.3.4). 
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6.3.1 .4 Response to MBMS Notification 



If the MBMS notification indicates that no counting shall be performed and contains no MBMS p-t-m channel 
description, the mobile station shall remain in or enter non-DRX mode and start timer T3214. Upon expiry of timer 
T3214, a mobile station in packet idle mode or MAC-Idle state (respectively broadcast-multicast receive mode) shall 
enter DRX mode (respectively remain in broadcast-multicast receive mode) and discard the corresponding notification. 
Upon reception of an MBMS ASSIGNMENT message for that session, the mobile station shall stop timer T3214 and 
shall proceed as described in sub-clause 7.7.2.2. 

While timer T3214 is running, the mobile station shall stop timer T3214 if: 

Any other procedure on PCCCH not related to MBMS is triggered. The mobile station shall then proceed as per 
that procedure. 

A notification is received for a higher priority session. The mobile station shall then proceed as per that 
notification. Depending on its capabilities, the MS may act upon the notification for the lower priority MBMS 
session provided it does not affect any of the following procedures for the higher priority MBMS session: 
response to MBMS notification (see present sub-clause), establishment of MBMS bearer upon receipt of MBMS 
ASSIGNMENT (see sub-clause 7.7.2.2), MBMS packet access procedure (see sub-clause 7.7.1). 

If the MBMS notification indicates that counting shall be performed the mobile station shall perform an MBMS packet 
access procedure, as described in sub-clause 7.7.1. 

If the MBMS notification includes an MBMS p-t-m channel description the mobile station shall set and start the session 
duration timer for this MBMS session with a value equal to the Estimated Session Duration (included in the MBMS 
Session Parameters List) and shall use information received on the PBCCH to decode the channel descriptions 
contained in the assignment. If frequency hopping is applied, the mobile station shall use the last CA (Cell Allocation) 
received on PBCCH to decode the Mobile Allocation. Alternatively, the network may provide a Mobile Allocation in 
the assignment. If an MBMS Radio Bearer Starting Time is indicated, the mobile station shall monitor PCCCH until the 
point in time denoted by the MBMS Radio Bearer Starting Time. The mobile station shall then switch to the assigned 
PDCHs and start timer T3190. If the MBMS Radio Bearer Starting Time has already elapsed or is not present, the 
mobile station shall switch to the assigned PDCHs and start timer T3190. The timer T3190 is restarted when receiving 
the first valid RLC data block for that session. In EGPRS TBF mode T3190 is also restarted when receiving an 
erroneous RLC data block for which the header is correctly received and which addresses the mobile station. The 
mobile station is not allowed to send normal bursts on the uplink unless it has a valid timing advance, and is assigned an 
MS_ID for that session. If the mobile station receives more than one MBMS notification including an MBMS p-t-m 
channel description for that same session while it monitors PCCCH, it shall act upon the most recently received 
assignment for that session and shall ignore the previous assignment. 

On expiry of timer T3190, the mobile station shall abort the procedure and return to packet idle mode or MAC-Idle 
state. The mobile station in broadcast/multicast receive mode shall abort the procedure and remain in 
broadcast/multicast receive mode. 

6.3.2 Notification to mobile station in pacl^et transfer mode or in dual 
transfer mode 

6.3.2.1 General 

MBMS notification initiation using PACCH applies when sending an MBMS notification to a mobile station or a group 
of mobile stations that is/are in packet transfer mode or in dual transfer mode. 

6.3.2.2 MBMS Notification using the PACCH 

The network may send the PACKET MBMS ANNOUNCEMENT message on any PDCH. 

Upon receipt of a PACKET MBMS ANNOUNCEMENT message containing a TMGI and optionally an MBMS 
Session Identity corresponding to an MBMS session the mobile station is required to receive, the mobile station shall 
pass an indication including the TMGI, and when available the MBMS Session Identity, to the upper layers. If the 
Restriction Timer is included in the received PACKET MBMS ANNOUNCEMENT message, the mobile station shall 
set and start an instance of the T3222 to the value indicated in the Restriction Timer field, otherwise if the Estimated 
Session Duration is included in the received PACKET MBMS ANNOUNCEMENT message the mobile station shall 
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set and start both an instance of the T3222 and the session duration timer for this MBMS session with a value equal to 
the Estimated Session Duration. The mobile station shall store the MBMS specific information contained in the 
PACKET MBMS ANNOUNCEMENT message. 

If T3222 expires the mobile station shall discard the stored MBMS information associated with this instance of T3222. 

6.3.2.3 Response to MBMS Notification received on PACCH 

If the mobile station enters packet idle mode and completes the Transfer non-DRX mode period before the expiry of 
T3222 or where no instance of T3222 was set and the PACKET MBMS ANNOUNCEMENT message did not include 
the MBMS p-t-m channel description, the mobile station shall stop T3222, if started, and initiates the MBMS Packet 
Access Procedure on a PCCCH (sub-clause 7.7.1.2) or, if a packet control channel does not exist, on a CCCH (sub- 
clause 7.7.1.3) or, if the PACKET MBMS ANNOUNCEMENT message contained uplink resource description for an 
MPRACH, on that MPRACH (sub-clause 7.7.1.4). 

Any MPRACH description or MBMS p-t-m channel description stored from a previously received PACKET MBMS 
ANNOUNCEMENT message shall be deleted after the mobile station completes cell reselection or after a handover 
procedure is completed. 

If the mobile station enters packet idle mode before the expiry of T3222 and the PACKET MBMS ANNOUNCEMENT 
message included the MBMS p-t-m channel description, the mobile station shall stop T3222 and shall start listening to 
downlink RLC blocks identified by the assigned TFI on the defined PDCHs either at the point in time denoted by the 
MBMS Radio Bearer Starting Time, if present and not already elapsed, or immediately otherwise. 

The mobile station shall follow the procedures described in sub-clause 6.3.1.4. 



7 Medium Access Control (MAC) procedures on 

PCCCH 

7.0 General 

The establishment of a Temporary Block Flow (TBF) can be initiated by either the mobile station or the network. 

The request for establishment of a TBF on PCCCH, if allocated in the cell, is described in this sub-clause. If no PCCCH 
is allocated in the cell, the establishment of a TBF occurs on CCCH as described in 3GPP TS 44.018. 

For mobile stations in packet idle mode on PCCCH, measurement reports messages are sent on temporary fixed 
allocations without the establishment of an uplink TBF (see sub-clause 7.3). 

7.0a Support of multiple TBF procedures 

If the mobile station supports multiple TBF procedures, the mobile station shall indicate its support in the Multiple TBF 
Capability field in the MS Radio Access Capability 2 IE. If the network supports multiple TBF procedures, the network 
shall indicate its support in the Multiple TBF Capability field in the GPRS Cell Options IE. 

If both the network and the mobile station support multiple TBF procedures, and if more than one request is received 
from upper layers to transfer upper layer PDUs for more than one PFC before the packet access procedure can be 
initiated by the mobile station, then the mobile station may initiate a packet access procedure requesting multiple TBFs. 

During multiple TBF procedures in sub-clause 7: 

The mobile station shall support the PACKET RESOURCE REQUEST message to request a single uplink TBF. 

The mobile station may send the PACKET RESOURCE REQUEST message to request multiple uplink TBFs in 
the second phase of a two-phase access. 

- The network shall support the PACKET UPLINK ASSIGNMENT message to assign a single uplink TBF. 
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- The network may send the MULTIPLE TBF UPLINK ASSIGNMENT message to assign one or more uplink 
TBFs to a mobile station that requested multiple TBFs in the PACKET RESOURCE REQUEST message. In this 
sub-clause this message shall only be sent in response to a multiple uplink resource request in the second part of 
a two-phase access. 

7.1 TBF establishment initiated by the mobile station on 
PCCCH 

The purpose of the packet access procedure is to establish a TBF to support the transfer of upper-layer PDUs in the 
direction from the mobile station to the network. Packet access shall be done on PCCCH, as defined in this sub-clause, 
if a PCCCH exists. Otherwise, packet access shall be done on CCCH, as defined in 3GPP TS 44.018. The packet access 
can be done in either one phase (sub-clause 7.L2) or in two phases (sub-clauses 7.L2 and 7.L3). 

TBF establishment can also be done on PACCH if a TBF for transfer of upper-layer PDUs in the direction from the 
network to the mobile station is already established (see sub-clause 8.1.2.5). TBF establishment can also be done on 
PACCH if the mobile station is releasing a TBF for transfer of upper-layer PDUs in the direction from the mobile 
station to the network and TBF for transfer of upper-layer PDUs in the direction from the network to the mobile station 
is not established (see sub-clause 9.3.2.4 and sub-clause 9.3.3.3). 

If the mobile station is in dedicated mode and both the network and the mobile station support DTM, the establishment 
of a TBF shall be performed by the DTM assignment procedures on the main DCCH, as defined in 3GPP TS 44.018. 

The packet access procedure is initiated by the mobile station. Initiation is triggered by a request from upper layers to 
transfer an upper-layer PDU. The request from upper layers specifies throughput, RLC mode, an optional PFI, and a 
Radio Priority to be associated with the packet transfer or indicates that the packet to be transferred contains signalling. 

A packet access procedure requesting multiple TBFs may be initiated by the mobile station if multiple TBF procedures 
are supported in the network and the mobile station (see sub-clause 7.0). Initiation is triggered when the mobile station 
receives more than one request from upper layers to transfer upper-layer PDUs before the packet access procedure can 
be initiated. Each request from upper layers specifies a PFI, RLC mode. Radio Priority and optionally an LLC mode to 
be associated with the packet transfer or indicates that the packet to be transferred contains signalling. 

Upon such a request: 

if access to the network is allowed (sub-clause 7.1.1), the mobile station shall initiate the packet access 
procedure as defined in sub-clause 7.1.2.1; 

otherwise, the RR sublayer in the mobile station shall reject the request. 

If the request from upper layers indicates signalling, the highest Radio Priority shall be used at determination if access 
to the network is allowed, and the acknowledged RLC mode shall be requested. 

If both the mobile station and the BSS support multiple TBF procedures, the BSS may order its preferred RLC mode 
when establishing uplink TBF(s), independently of the RLC mode requested by the mobile station. 

7.1 .1 Permission to access the network 

The network broadcasts on PBCCH and PCCCH the list of authorised access classes and authorised special access 
classes in the ACC_CONTR_CLASS parameter. 

Access to the network is allowed if the mobile station is a member of at least one authorised access class or special 
access class as defined in 3GPP TS 22.011. 

7.1 .2 Initiation of a TBF establishment 

7.1 .2.1 Initiation of the packet access procedure 

The mobile station shall initiate the packet access procedure by scheduling the sending of PACKET CHANNEL 
REQUEST messages on the PRACH corresponding to its PCCCH_GROUP and simultaneously leaving the packet idle 
mode. The mobile station shall use the last access parameters received on PBCCH. At sending of the first PACKET 
CHANNEL REQUEST message, the mobile station shall store the value for the Retry (R) bit to be transmitted in all the 
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subsequent MAC headers as 'MS sent channel request message once'. If a second PACKET CHANNEL REQUEST 
message is sent, the mobile station shall change the value for the Retry (R) bit to 'MS sent channel request message 
once or more'. 

While waiting for a response to the PACKET CHANNEL REQUEST message, the mobile station shall monitor the full 
PCCCH corresponding to its PCCCH_GROUP. The mobile station shall perform signal strength measurements as they 
are defined for packet idle mode, see 3GPP TS 45.008. 

While monitoring the full PCCCH, the mobile station shall decode any occurrence of the PERSISTENCE_LEVEL 
parameter included in a message received on PCCCH. When the mobile station receives the PERSISTENCE_LEVEL 
parameter, the value of the PERSISTENCE_LEVEL parameter shall be taken into account at the next PACKET 
CHANNEL REQUEST attempt that follows. 

A mobile station that is IMSI attached (GPRS class A or B mode of operation) shall respond to a PACKET PAGING 
REQUEST message indicating an RR connection establishment. For that purpose, the mobile station may abort the 
packet access procedure, according to the conditions stated in sub-clause 6.1.4. The mobile station shall not respond to a 
PACKET PAGING REQUEST message indicating TBF estabHshment. 

A mobile station that is not IMSI attached (GPRS class C mode of operation) shall not respond to any type of PACKET 
PAGING REQUEST messages during the packet access procedure, it shall only decode the PERSISTENCE_LEVEL 
parameter, if that is included in the message. 

The PACKET CHANNEL REQUEST messages are sent on PRACH and contain an indication of the type of access and 
parameters required to indicate the mobile station's demand of radio resource. 

There are two formats of the PACKET CHANNEL REQUEST message containing either 8 bits or 11 bits of 
information. The format to be applied on PRACH is controlled by the parameter ACC_BURST_TYPE which is 
broadcast on PBCCH. The access type to be used in the PACKET CHANNEL REQUEST message for a non-EGPRS 
TBF mode capable MS or an EGPRS TBF mode capable MS in a non-EGPRS capable cell depends on the purpose of 
the packet access procedure as follows: 

If the purpose of the packet access procedure is to request multiple TBFs, the mobile station shall indicate 'Two 
phase access' in the PACKET CHANNEL REQUEST message. 

If the purpose of the packet access procedure is to request a single TBF, the mobile station shall indicate one of 
the following access causes: 

If the mobile station intends to use the TBF to send user data, it shall request two phase access if the 
requested RLC mode is unacknowledged mode. If the requested RLC mode is acknowledged mode, the 
mobile station shall request either one phase access or two phase access. In case of two phase access, if both 
the mobile station and the BSS support multiple TBF procedures, the BSS may order its preferred RLC mode 
when establishing an uplink TBF, overriding the mobile station request. 

If the purpose of the packet access procedure is to send a Page Response, the mobile station shall indicate 
'Page Response' in the PACKET CHANNEL REQUEST message. 

If the purpose of the packet access procedure is to send a Cell update (the mobile station was in GMM 
READY state before the cell reselection) the mobile station shall indicate 'Cell Update' in the PACKET 
CHANNEL REQUEST message. 

If the purpose of the packet access procedure is for any other Mobility Management procedure, the mobile 
station shall indicate 'MM Procedure' in the PACKET CHANNEL REQUEST message. 

If the purpose of the packet access procedure is to send a Measurement Report, the mobile station shall 
indicate 'Single block without TBF establishment' in the PACKET CHANNEL REQUEST message. 

If the purpose of the packet access procedure is to send a PACKET PAUSE message, the mobile station shall 
indicate 'Single block without TBF establishment' in the PACKET CHANNEL REQUEST message. Upon 
the first attempt to send a PACKET CHANNEL REQUEST message the mobile station shall start timer 
T3204. If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message before expiry of 
timer T3204, the mobile station shall ignore the message. 

If the purpose of the packet access procedure is to send an MBMS SERVICE REQUEST message to the 
network, the mobile station shall indicate 'Single block MBMS access' in the PACKET CHANNEL 
REQUEST message. 
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EGPRS TBF mode capable MSs shall monitor the GPRS Cell Options IE on the PBCCH (PSI1/PSI13) for the cell's 
EGPRS capability. In the GPRS Cell Options IE it is also indicated if the EGPRS PACKET CHANNEL REQUEST is 
supported in the cell. The following table specifies which message and which access type shall be used by an EGPRS 
mobile station when accessing an EGPRS capable cell depending on the purpose of the packet access procedure; this 
table covers the case where PBCCH is present in the cell (see 3GPP TS 44.018 for the case where PBCCH is not 
present in the cell): 



Purpose of the packet 
access procedure 


EGPRS PACKET CHANNEL REQUEST 
supported in the cell 


EGPRS PACKET CHANNEL REQUEST 
not supported in the cell 


User data transfer - 
requested RLC mode = 
unacknowledged 


EGPRS PACKET CHANNEL REQUEST 
with access type = Two-phase access' 


PACKET CHANNEL REQUEST with 
access type = 'Two-phase access' 
(N0TE1) 


User data transfer - 
requested RLC mode = 
acknowledged 


EGPRS PACKET CHANNEL REQUEST 
with access type = 'One-phase access' or 
'Two-phase access' 


PACKET CHANNEL REQUEST with 
access type = 'Two-phase access' 
(N0TE1) 


Upper layer signalling 
transfer (e.g. page 
response, cell update, IVIM 
signalling, etc) 


EGPRS PACKET CHANNEL REQUEST 
with access type = 'signalling' 


PACKET CHANNEL REQUEST with 
access type = 'Two-phase access' 


Sending of a measurement 
report or of a PACKET 
CELL CHANGE FAILURE 


PACKET CHANNEL REQUEST with access type = 'Single block without TBF 
establishment' (NOTE 1) 


Sending of a PACKET 
PAUSE message 


PACKET CHANNEL REQUEST with access type = 'Single block without TBF 
establishment' (NOTE 1) (NOTE 2) 


Sending of an MBMS 
Service Request message 


PACKET CHANNEL REQUEST with access type = 'Single block MBMS access' 


NOTE 1 : The format to be used for the PACKET CHANNEL REQUEST message is defined by the parameter 

ACC BURST TYPE. 
NOTE 2: Upon the first attempt to send a PACKET CHANNEL REQUEST message the mobile station shall start 

timer T3204. If the mobile station receives a PACKET DOWNLINK ASSIGNIVIENT message before expiry 

of timer T3204, the mobile station shall ignore the message. 



7.1.2.1.1 



Access persistence control on PRACH 



The mobile station shall make maximally M + 1 attempts to send a PACKET CHANNEL REQUEST (respectively 
EGPRS PACKET CHANNEL REQUEST) message. 

After sending each PACKET CHANNEL REQUEST (respectively EGPRS PACKET CHANNEL REQUEST) 
message, the mobile station shall listen to the full PCCCH corresponding to its PCCCH_GROUP. 

The PRACH Control Parameters IE contains the access persistence control parameters and shall be broadcast on 
PBCCH and PCCCH. The parameters included in the PRACH Control Parameters IE are: 

- MAX_RETRANS, for each radio priority i (i = 1,2,3,4); 



PERSISTENCE_LEVEL, which consists of the PERSISTENCE_LEVEL P(i) for each radio priority i (i = 1, 2, 
3, 4); where P(i) g {0, 1, ...14, 16}. If the PRACH Control Parameters IE does not contain the 
PERSISTENCE_LEVEL parameter, this shall be interpreted as if P(i) = for all radio priorities; 



- TX_INT. 

The mobile station shall start timer T3186 at the beginning of the Packet Access Procedure. At expiry of timer T3186, 
the packet access procedure shall be aborted, packet access failure shall be indicated to upper layers and the mobile 
station shall return to packet idle mode or MAC-Idle state. 

The first attempt to send a PACKET CHANNEL REQUEST (respectively EGPRS PACKET CHANNEL REQUEST) 
message, may be initiated at the first available PRACH block on the PDCH defined by the PCCCH_GROUP for the 
mobile station (see 3GPP TS 45.002). The mobile station shall chose one of the four TDMA frames within the selected 
PRACH block randomly with a uniform probability distribution. 

For each attempt, the mobile station shall draw a random value R with uniform probability distribution in the set 

{0, 1, ..., 15}. The mobile station is allowed to transmit a PACKET CHANNEL REQUEST message if P(i), where i is 

the radio priority of the TBF being established, is less or equal to R. 
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After each attempt, the S and T parameters are used to determine the next TDMA frame in which it may be allowed to 
make a successive attempt. The number of TDMA frames belonging to the PRACH on the PDCH defined by the 
PCCCH_GROUP for the mobile station between two successive attempts to send a PACKET CHANNEL REQUEST 
(respectively EGPRS PACKET CHANNEL REQUEST) message excluding the TDMA frames potentially containing 
the messages themselves is a random value drawn for each transmission with uniform probability distribution in the set 
{S,S + 1, ...,S+T-1}; 

Here: 

M is the value of the parameter MAX_RETRANS, belonging to the Radio Priority of the access; 

T is the value of the parameter TX_INT; 

S is the value of the parameter S. 

Having made M + 1 attempts to send a PACKET CHANNEL REQUEST (respectively EGPRS PACKET CHANNEL 
REQUEST) message, the mobile station shall stop timer T3186 and start timer T3170. At expiry of timer T3170, the 
packet access procedure shall be aborted, a random access failure shall be indicated to upper layer and the mobile 
station shall perform autonomous cell re-selection according to 3GPP TS 43.022. 

If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message while it is waiting for a response to a 
PACKET CHANNEL REQUEST (respectively EGPRS PACKET CHANNEL REQUEST) message, it shall abort the 
packet access procedure and respond to the PACKET DOWNLINK ASSIGNMENT message (see sub-clause 7.2.1). 
The mobile station shall then attempt establishment of an uplink TBF using the procedures defined in sub-clause 
8.1.2.5. 

7.1 .2.2 Packet assignment procedure 

7.1 .2.2.1 On receipt of a PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL 

REQUEST message 

On receipt of a PACKET CHANNEL REQUEST message, the network may assign a radio resource on one or more 
PDCHs to be used by the mobile station for the TBF in GPRS TBF mode. On receipt of an EGPRS PACKET 
CHANNEL REQUEST message, the network may assign a radio resource on one or more PDCHs to be used by the 
mobile station for the TBF in EGPRS TBF mode or GPRS TBF mode. 

The allocated PDTCH and PACCH resource is assigned to the mobile station in a PACKET UPLINK ASSIGNMENT 
message, sent on any PAGCH block on the same PCCCH on which the network has received the PACKET CHANNEL 
REQUEST or EGPRS PACKET CHANNEL REQUEST message. The Packet Request Reference information element 
shall be used to address the mobile station and frequency parameters shall be included. 

The mobile station may use information received on PBCCH, BCCH or a previous assignment message to decode the 
frequency parameters contained in the assignment message. If the mobile station detects an invalid Frequency 
Parameters information element in the assignment message, it shall abort the procedure, if required initiate a partial 
acquisition of PBCCH or BCCH information, and may then re-initiate this procedure. 

If the dynamic allocation medium access mode is commanded, the network shall include the USE values allocated for 
PDCHs in the PACKET UPLINK ASSIGNMENT message. 
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Unless the mobile station has indicated a "Single Block Without TBF Establishment" or "Single block MBMS access" 
in a PACKET CHANNEL REQUEST message, the mobile station shall perform a two phase access if the 
PACKET UPLINK ASSIGNMENT message includes a Single Block Allocation struct or a Multi Block Allocation 

struct. 

If the PACKET UPLINK ASSIGNMENT message includes Dynamic Allocation struct and the MS has not requested 
'Single Block Without TBF Establishment', 'Two phase access' , or 'Single Block MBMS access', the mobile station 
shall perform a one phase access. 

In case the MS requested two phase access, the procedures in sub-clause 7.L3 shall apply. 

A mobile station that has indicated "Single Block Without TBF Establishment" in the PACKET CHANNEL REQUEST 
message for the purpose of sending a measurement report shall send a measurement report according to sub-clause 
7.3.1. 

A mobile station that has indicated "Single Block Without TBF Establishment" in the PACKET CHANNEL REQUEST 
message for the purpose of sending a PACKET CELL CHANGE FAILURE message shall send that message according 
to sub-clause 8.4.2. 

On receipt of a PACKET UPLINK ASSIGNMENT message corresponding to one of its 3 last PACKET CHANNEL 
REQUEST or EGPRS PACKET CHANNEL REQUEST messages the mobile station shall stop timers T3186 and 
T3170 if running and stop sending PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST 

messages. 

If the PACKET UPLINK ASSIGNMENT message does not specify a TBF starting time, the mobile station shall switch 
to the assigned PDCHs, start timer T3164 if dynamic or extended dynamic allocation is assigned and proceed with 
contention resolution of the one phase packet access procedure according to sub-clause 7.1.2.3 (A/Gb mode) or 
3GPP TS 44.160 (lu-mode) or in case of EGPRS, sub-clause 7.1.2.3a (A/Gb mode) or 3GPP TS 44.160 (lu-mode). 

A PACKET UPLINK ASSIGNMENT message may indicate an assignment starting time in the TBF Starting Time 
parameter. The mobile station shall monitor the full PCCCH until the point in time denoted by the TBF Starting Time. 
Thereafter it shall switch to the assigned PDCHs. If dynamic or extended dynamic allocation is assigned, the mobile 
station shall start timer T3164. Regardless of which allocation mode is used, the mobile station shall proceed with the 
contention resolution defined in sub-clause 7.1.2.3 (A/Gb mode) or 3GPP TS 44.160 (lu-mode) or in case of EGPRS, 
sub-clause 7.1.2.3a (A/Gb mode) or 3GPP TS 44.160 (lu-mode). If the mobile station receives more than one 
PACKET UPLINK ASSIGNMENT message, it shall act upon the most recently received message and shall ignore the 
previous message. 

When the mobile station switches to the assigned PDCHs, it shall take the power control parameters received in the 
PACKET UPLINK ASSIGNMENT message into account, perform signal strength measurements and apply output 
power control procedures as they are defined for packet transfer mode or MAC-Shared state (see 3GPP TS 45.008). 

On receipt of a PACKET CHANNEL REQUEST message with establishment cause indicating "Two Phase Access 
Request" , "Single block without TBF establishment" or "Single block MBMS access", the network may allocate a 
single radio block on an uplink PDCH. In order to force the mobile station to make a two phase access, the network 
may allocate a single radio block on an uplink PDCH on receipt of a PACKET CHANNEL REQUEST message with 
any of the other access types. 

On receipt of an EGPRS PACKET CHANNEL REQUEST message with establishment cause indicating "Two Phase 
Access Request", the network may allocate a Multi Block allocation on an uplink PDCH. In order to force the mobile 
station to make a two phase access, the network may allocate a Multi Block allocation on an uplink PDCH on receipt of 
a EGPRS PACKET CHANNEL REQUEST message with any of the other access types. 

If the mobile station has been allocated a single block (respectively a Multi Block allocation) in the 
PACKET UPLINK ASSIGNMENT message and the mobile station has not indicated "Single block without TBF 
establishment" (respectively "Two phase access") in the PACKET CHANNEL REQUEST (respectively EGPRS 
PACKET CHANNEL REQUEST) message or "Single block MBMS access" in the PACKET CHANNEL REQUEST 
message, the mobile station shall proceed with the two phase packet access procedure according to sub-clause 7.1.3 
(A/Gb mode) or 3GPP TS 44.160 (lu-mode). 

If the mobile station has been allocated a single block in the PACKET UPLINK ASSIGNMENT message and the 
purpose of the packet access procedure is to send a Measurement Report message and the mobile station has indicated 
"Single block without TBF establishment" in the PACKET CHANNEL REQUEST message, the mobile station shall 
proceed according to sub-clause 7.3.1. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 66 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

If the mobile station has been allocated a single block in the PACKET UPLINK ASSIGNMENT message and the 
purpose of the packet access procedure is to send a PACKET PAUSE message and the mobile station has indicated 
"Single block without TBF establishment" in the PACKET CHANNEL REQUEST message, the mobile station shall 
proceed according to sub-clause 7.6. 

If the mobile station has been allocated a single block in the PACKET UPLINK ASSIGNMENT message and the 
purpose of the packet access procedure is to send an MBMS SERVICE REQUEST message and the mobile station has 
indicated "Single block MBMS access" in the PACKET CHANNEL REQUEST message, the mobile station shall 
proceed according to sub-clause 7.7.L2.2. 

7.1.2.2.1a Acquisition of MS Radio Access Capability information within EGPRS TBF 

establishment procedure 

When assigning an EGPRS TBF, the network may request information about radio access capabilities of the mobile 
station on one or several frequency bands within the PACKET UPLINK ASSIGNMENT message; the list of frequency 
bands is ordered by the network starting with the most important and ending with the least important one. The mobile 
station shall provide the network with its radio access capabilities for the frequency bands it supports, in the same 
priority order as the one specified by the network, by sending a PACKET RESOURCE REQUEST message, and an 
ADDITIONAL MS RADIO ACCESS CAPABILITIES message if all the requested information does not fit in the 
PACKET RESOURCE REQUEST. If the mobile station does not support any frequency band requested by the 
network, it shall report its radio access capabilities for the BCCH frequency band. The mobile station shall indicate in 
the PACKET RESOURCE REQUEST if it will send more information about its radio access capabilities in the 
ADDITIONAL MS RADIO ACCESS CAPABILITIES message. The PACKET RESOURCE REQUEST and the 
ADDITIONAL MS RADIO ACCESS CAPABILITIES messages shall be sent within the one or two first radio blocks 
allocated for the mobile station on the assigned PDCH. The mobile station shall include the TLLI in these two messages 
until contention resolution. After that, the mobile station may use either the uplink TFI or the TLLI when these 
messages are repeated. 

When constructing the PACKET RESOURCE REQUEST and ADDITIONAL MS RADIO ACCESS CAPABILITIES 
messages the mobile station shall take care that these messages fit in one UL radio block each. 

The network may request a retransmission of the PACKET RESOURCE REQUEST and the ADDITIONAL MS 
RADIO ACCESS CAPABILITIES messages. A request for retransmission of one or both of these messages shall be 
indicated in the PACKET UPLINK ACK/NACK or the PACKET UPLINK ASSIGNMENT message. The mobile 
station has to indicate within the PACKET RESOURCE REQUEST message if the message is a retransmitted one. 

7.1 .2.2.2 Packet access queuing notification procedure 

The network may send to the mobile station a PACKET QUEUING NOTIFICATION message. The PACKET 
QUEUING NOTIFICATION message shall be sent on the same PCCCH on which the network has received the 
PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST message. It contains a Temporary 
Queuing Identity which is later used to identify the mobile station (either when polling or sending an assignment). 

On receipt of a PACKET QUEUING NOTIFICATION message corresponding to one of its 3 last PACKET 
CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST messages, the mobile station shall stop timers 
T3170 and T3186 if running, start timer T3162, and stop sending PACKET CHANNEL REQUEST or EGPRS 
PACKET CHANNEL REQUEST messages. It shall continue to listen to the full PCCCH corresponding to its 
PCCCH_GROUP. If the mobile station receives a PACKET QUEUING NOTIFICATION message while waiting for 
the TBF Starting Time of a valid PACKET UPLINK ASSIGNMENT message, the mobile station shall ignore the 
PACKET QUEUEING NOTIFICATION message. 

The network may send to the mobile station a PACKET UPLINK ASSIGNMENT message following a PACKET 
QUEUING NOTIFICATION message. In this case, the reference address to the mobile station shall be the Temporary 
Queuing Identity received in the PACKET QUEUING NOTIFICATION message. 

On receipt of a PACKET UPLINK ASSIGNMENT message following a PACKET QUEUING NOTIFICATION 
message, the mobile station shall stop timer T3162 and follow the procedures defined in sub-clause 7.1.2.2.1. 

At expiry of timer T3162, the packet access procedure shall be aborted and a packet access failure shall be indicated to 
the upper layer and the mobile station shall return to packet idle mode or MAC -Idle state. 

If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message, it shall abort the packet access 
queuing notification procedure and respond to the PACKET DOWNLINK ASSIGNMENT message (see sub- 
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clause 7.2.1). The mobile station shall then attempt establishment of an uplink TBF using the procedures defined in sub- 
clause 8.1.2.5. 

7.1 .2.2.3 Packet polling procedure 

The network may send to the mobile station a PACKET POLLING REQUEST message after having sent a PACKET 
QUEUING NOTIFICATION message. The PACKET POLLING REQUEST message shall be sent on the same PDCH 
on which the network has received the PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST 
message. The mobile station shall be addressed by the Temporary Queuing Identity. 

On receipt of a PACKET POLLING REQUEST message, the mobile station shall respond to the network with the 
PACKET CONTROL ACKNOWLEDGEMENT message in the reserved uplink radio block specified by the RRBP 
field. The reserved block is considered as a one block PACCH allocation. 

7.1 .2.2.4 Packet access reject procedure 

The network may, as response to a PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST 
message, send to the mobile station a PACKET ACCESS REJECT message on any PAGCH block on the same PCCCH 
on which the channel request message was received. This message contains the request reference with time of reception 
of the PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST message and optionally a 
WAITJNDICATION field in the Reject structure of the PACKET ACCESS REJECT message. 

On receipt of a PACKET ACCESS REJECT message containing a Reject structure addressed to the mobile station, 
where the Packet Request Reference in the Reject structure corresponds to one of its 3 last PACKET CHANNEL 
REQUEST or EGPRS PACKET CHANNEL REQUEST messages: 

- The mobile station shall stop timer T3 1 86, stop sending PACKET CHANNEL REQUEST or EGPRS PACKET 
CHANNEL REQUEST messages, start timer T3172 with the value indicated in the WAIT_INDICATION field, 
start timer T3170 if it has not already been started and listen to the downlink PCCCH until timer T3170 expires. 
During this time, the mobile station shall ignore additional PACKET ACCESS REJECT messages, but on 
reception of any PACKET UPLINK ASSIGNMENT message corresponding to any other of its 3 last PACKET 
CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST messages the mobile station shall stop 
timers T3170 and T3172 if running, and follow the procedure defined in sub-clause 7.1.2.2.1. 

- If no PACKET UPLINK ASSIGNMENT message is received before expiration of timer T3 170, the mobile 
station shall indicate a packet access failure to upper layer and return to packet idle mode (listening to its paging 
channel). As an option the mobile station may stop timer T3170, indicate a packet access failure to upper layer 
and return to packet idle mode as soon as it has received responses from the network on all or, in case more than 
3 were sent, the last 3 of its PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST 
messages. 

If an erroneous PACKET UPLINK ASSIGNMENT message (e.g. the mobile station has been assigned more 
PDCHs than it supports according to its multislot class) addressed to the mobile station is received before 
expiration of timer T3170, the mobile station shall stop T3170 and act as stated in sub-clause 7.1.4. 

- If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message, it shall stop timer T3 170 if 
running and respond to the PACKET DOWNLINK ASSIGNMENT message (see sub-clause 7.2.1). 

The mobile station is not allowed to make a new attempt for packet access in the same cell until timer T3172 
expires, but may attempt packet access in another cell after successful cell reselection for radio conditions 
reasons (see 3GPP TS 45.008). InA/Gb mode, a mobile station that is IMSI attached (GPRS class A or B mode 
of operation) may attempt to enter the dedicated mode in the same cell before timer T3172 has expired. During 
the time T3172 is running, the mobile station shall ignore all received PACKET PAGING REQUEST messages 
except paging request to trigger RR connection establishment. 

The value of the WAITJNDICATION field (i.e. timer T3 172) relates to the cell from which it was received. 

7.1 .2.3 Contention resolution at one phase access 

The TLLI is used to uniquely identify the mobile station when sending on uplink. Every RLC data block that is sent on 
the TBF shall include the TLLI of the mobile station, until the contention resolution is completed on the mobile station 
side. If MCS-7, MCS-8 or MCS-9 is used for the transmission of the TLLI in EGPRS TBF mode (i.e. the RLC/MAC 
block is carrying two RLC data blocks), the TLLI shall be inserted in both RLC data blocks. The TLLI shall also be 
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included in the PACKET RESOURCE REQUEST and the ADDITIONAL MS RADIO ACCESS CAPABILITIES 
messages, if those are sent during the contention resolution. 

The retransmission of an RLC data block shall include the TLLI (or the TLLI and the PFI field), if the RLC data block 
was originally transmitted including these fields, also if the retransmission occurs after the completion of the contention 
resolution. 

At sending of the first RLC data block, the mobile station shall stop timer T3164, set counter N3104 to 1, and start timer 
T3166. The counter N3104 shall be stepped each time the mobile station sends an RLC data block. 

The network shall respond by including the TLLI in the PACKET UPLINK ACK/NACK message after the first 
correctly received RLC data block that comprises the TLLI. In EGPRS TBF mode, the network may instead respond by 
addressing the mobile station with the TFI of the assigned TBF and including the TLLI (in the 
CONTENTION_RESOLUTION_TLLI field) in a PACKET UPLINK ASSIGNMENT message, if the resources 
allocated for the TBF need to be reallocated (see sub-clauses 8.1.1.1.2). 

The contention resolution is completed on the network side when the network receives an RLC data block that 
comprises the TLLI value that identifies the mobile station and the TFI value associated with the TBF. 

The contention resolution is successfully completed on the mobile station side when the mobile station receives a 
PACKET UPLINK ACK/NACK message addressing the mobile station with the TFI value associated with the uplink 
TBF and including the same TLLI value that the mobile station has included in the RLC header of the first RLC data 
blocks, or alternatively, in EGPRS TBF mode, a PACKET UPLINK ASSIGNMENT message addressing the mobile 
station with the TFI value associated with the uplink TBF and including the same TLLI value that the mobile station 
included in the RLC header of the first RLC data blocks. The mobile shall then stop timer T3166 and counter N3104. 

The contention resolution has failed on the mobile station side when the counter N3104 reaches its maximum value, or 
timer T3166 expires. The contention resolution also fails, if the mobile station receives a PACKET UPLINK 
ACK/NACK message or in EGPRS TBF mode alternatively a PACKET UPLINK ASSIGNMENT message addressing 
the mobile station with the TFI associated with the uplink TBF and including a TLLI value other than that the mobile 
station included in the RLC header of the first RLC data blocks; in such a case, the mobile station shall not transmit a 
PACKET CONTROL ACKNOWLEDGEMENT in the uplink radio block specified if a valid RRBP field is received as 
part of the PACKET UPLINK ACK/NACK message or in EGPRS TBF mode alternatively as part of the 
PACKET UPLINK ASSIGNMENT message. 

In case of a contention resolution failure on the mobile station side, the mobile station shall reset the counter N3104 and 
stop timer T3166, if not expired. The mobile station shall stop transmitting on the TBF and reinitiate the packet access 
procedure, unless the packet access procedure has already been attempted four times. In that case, a TBF failure has 
occurred, see sub-clause 7.2.2. 

7.1 .2.3a RLC/MAC procedures during contention resolution 

During the contention resolution, the mobile station may receive a non-distribution RLC/MAC control message 
addressing the mobile station by TLLI, or the TFI value associated with the uplink TBF. The mobile station shall act on 
that message using the procedure defined for the message when it is received in packet transfer mode during operation 
on an uplink TBF (see clause 8), with the following restrictions: 

- The mobile station shall not accept a PACKET MEASUREMENT ORDER message, a PACKET CELL 
CHANGE ORDER message and a PACKET POWER CONTROL/TIMING ADVANCE message addressing 
the mobile station with the TFI value associated with the uplink TBF; 

- The mobile station shall not accept a PACKET DOWNLINK ASSIGNMENT or a PACKET TIMESLOT 
RECONFIGURE message. 

If a valid RRBP field is received as part of the RLC/MAC control block, the mobile station shall transmit a PACKET 
CONTROL ACKNOWLEDGEMENT message in the uplink radio block specified (see sub-clause 10.4.5) if it acts on 
the message; the mobile station may transmit a PACKET CONTROL ACKNOWLEDGEMENT message in the uplink 
radio block specified if it does not act on the message. 

If during the contention resolution, upper layers request the transfer of another upper layer PDU with a different PFI, a 
different Radio Priority, a different peak throughput class or a different RLC mode than the one which is in transfer, 
then the procedures as described in packet transfer mode (see sub-clause 8.1.1.1.2) shall be applied by the mobile 
station. 
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In either case, the mobile station shall continue with the contention resolution on the uplink TBF, till it either completes 
successfully or fails, or that the uplink TBF is released as a result of the procedure defined for the message that is 
received. 

7.1 .2.4 One phase packet access completion 

The one phase packet access procedure is completed upon a successful contention resolution. The mobile station has 
entered the packet transfer mode or MAC-Shared state. 

7.1.2.5 Timing Advance 

Initial timing advance may be provided in the PACKET UPLINK ASSIGNMENT in the 
TIMING_ADVANCE_VALUE field. 

Thereafter either the timing advance is updated with a PACKET POWER CONTROL/TIMING ADVANCE message 
or a continuous timing advance procedure is used. If a Timing Advance Index is included in the assignment message, 
the mobile station shall use the continuous timing advance procedure, using its allocation on PTCCH (see 
3GPP TS 45.010). Otherwise, the continuous timing advance procedure shall not be used. For the case where a 
TIMING_ADVANCE_VALUE field is not provided in the assignment message, the mobile station is not allowed to 
send normal bursts on the uplink until it receives a valid timing advance either through the continuous timing advance 
procedure or in a PACKET POWER CONTROL/TIMING ADVANCE message. 

7.1 .2.6 PFC procedure at one phase access 

If the PFC_FEATURE_MODE field indicates that the network supports PFC procedures in the system information and 
if a PFC exists for the LLC data to be transferred then the PFI shall be transmitted along with the TLLI of the mobile 
station in the RLC extended header during contention resolution. If the PFC_FEATURE_MODE field indicates that the 
network does not support PFC procedures, the mobile station shall not indicate a PFI value. If no valid PFI is allocated, 
the default mapping defined in sub-clause 5.5.1.9 shall be used. The PFI is not used for contention resolution but is 
included to indicate to the network which PFC shall initially be associated with the uplink TBF. 

7.1 .3 TBF establishment using two phase access 

The two phase access procedure defined in this sub-clause, is applicable also in the case when no PCCCH is provided in 
the cell. For that case, the first phase is defined in 3GPP TS 44.018. 

7.1 .3.1 Initiation of the Packet resource request procedure 

In the first phase of a two phase access in a cell provided with a PCCCH, the same procedures as for one phase access 
are used until the network sends a PACKET UPLINK ASSIGNMENT message including a Single Block Allocation 
struct or Multi Block Allocation struct, denoting two phase access to the mobile station. The Multi Block Allocation 
struct may be used only if the mobile station has EGPRS capability (i.e. the network received an EGPRS PACKET 
CHANNEL REQUEST message from the mobile station). In the PACKET UPLINK ASSIGNMENT message, the 
network reserves a limited resource on one PDCH to the mobile station where the mobile station may transmit a 
PACKET RESOURCE REQUEST message and optionally an ADDITIONAL MS RADIO ACCESS CAPABILITIES 
message. 

If PCCCH is provided in the cell, a two phase access can be initiated: 

by the network by ordering the mobile station to send a PACKET RESOURCE REQUEST message. The order 
is sent implicitly to the mobile station in the PACKET UPLINK ASSIGNMENT message by including either the 
Single Block Allocation struct or Multi Block Allocation struct; 

- by a mobile station, by requiring a two phase access in the PACKET CHANNEL REQUEST or EGPRS 

PACKET CHANNEL REQUEST message. In this case, if access is granted, the network shall order the mobile 
station to send a PACKET RESOURCE REQUEST message. The order is sent implicitly to the mobile station in 
the PACKET UPLINK ASSIGNMENT message by including the Single Block Allocation struct or Multi Block 
Allocation struct. 

If no PCCCH is provided in the cell, a two phase access can be initiated: 
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by the network or by a mobile station, as defined in 3GPP TS 44.018. 

When the mobile station has received the PACKET UPLINK ASSIGNMENT message it shall respond with a PACKET 
RESOURCE REQUEST message in the first allocated radio block. 

A mobile station supporting EGPRS shall indicate the EGPRS capability in the MS Radio Access Capability 2 IE of the 
PACKET RESOURCE REQUEST message. 

A mobile station supporting multiple TBF procedures shall set the Multiple TBF Capability flag in the MS Radio Access 
Capability 2 IE of the PACKET RESOURCE REQUEST message. 

When the mobile station switches to the assigned PDCH, it shall take the power control parameters received in the 
PACKET UPLINK ASSIGNMENT message into account, perform signal strength measurements and apply output 
power control procedures as they are defined for packet transfer mode (see 3GPP TS 45.008). 

At sending of the PACKET RESOURCE REQUEST message requesting a single uplink TBF, the mobile station shall 
start timer T3168. At sending of the PACKET RESOURCE REQUEST message requesting multiple TBFs, the mobile 
station shall start contention resolution timer T3188 and additionally one instance of T3168 for each of the resource 
requests for the transfer of upper layer PDUs. Furthermore, the mobile station shall not respond to 
PACKET DOWNLINK ASSIGNMENT or MULTIPLE TBF DOWNLINK ASSIGNMENT messages before 
contention resolution is completed on the mobile station side - but may acknowledge such messages if they contain a 
valid RRBP field. 

The mobile station may indicate in the PACKET RESOURCE REQUEST message the number of octets of user data it 
has to transfer. 

7.1 .3.2 Packet resource assignment for uplink procedure 

When assigning a Multi Block Allocation, the network may request information about radio access capabilities of the 
mobile station on one or several frequency bands within the PACKET UPLINK ASSIGNMENT message and allocate 
one or two radio blocks for uplink control messages accordingly; the list of frequency bands is ordered by the network 
starting with the most important and ending with the least important one. The mobile station shall provide the network 
with its radio access capabilities for the frequency bands it supports, in the same order of priority as specified by the 
network, by sending a PACKET RESOURCE REQUEST message in the first radio block on the assigned PDCH and an 
ADDITIONAL MS RADIO ACCESS CAPABILITIES message in the next radio block on the assigned PDCH, if the 
requested information does not fit in the PACKET RESOURCE REQUEST and two radio blocks have been allocated 
by the network. If the network does not provide an Access Technologies Request in the PACKET UPLINK 
ASSIGNMENT message or the mobile station does not support any frequency band requested by the network, it shall 
report its radio access capabilities for the frequency band of the BCCH carrier in the PACKET RESOURCE REQUEST 
message. 

The mobile station shall indicate in the PACKET RESOURCE REQUEST message, by setting the ADDITIONAL MS 
RAC INFORMATION AVAILABLE bit, if it will send more information about its radio access capabilities in the 
ADDITIONAL MS RADIO ACCESS CAPABILITIES message if it has been allocated two radio blocks, or if it would 
have sent more information but has been allocated only one radio block. If the mobile station has been allocated two 
radio blocks and the requested information fit in the PACKET RESOURCE REQUEST message, no ADDITIONAL 
MS RADIO ACCESS CAPABILITIES message shall be sent. Instead, some uplink control block (e.g. packet 
measurement report, packet uplink dummy control block) may be sent by the mobile station. 

The network may indicate in the next PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK 
ASSIGNMENT message a request for retransmission of the ADDITIONAL MS RADIO ACCESS CAPABILITIES 

message (see sub-clause 7.1.3.2.1). 

When constructing the PACKET RESOURCE REQUEST and ADDITIONAL MS RADIO ACCESS CAPABILITIES 
messages the mobile station shall take care that these messages fit in one uplink radio block each. 

If the network indicates that it supports packet flow procedures via the PFC_FEATURE_MODE in the system 
information, then the mobile station supporting PEC procedures shall indicate the initial PFI to be associated with the 
TBF in the PACKET RESOURCE REQUEST message. If the PFC_FEATURE_MODE field indicates that the network 
does not support PEC procedures, the mobile station shall not indicate a PFI value. If no valid PFI is allocated, the 
default mapping defined in sub-clause 5.5.1.9 shall be used. If the mobile station requests multiple TBFs in the 
PACKET RESOURCE REQUEST message, it shall indicate the PFI to be associated with each TBF. 
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7.1 .3.2.1 On receipt of a PACKET RESOURCE REOUEST message 

On receipt of a PACKET RESOURCE REQUEST message requesting a single uplink TBF scheduled with a Single 
Block or a Multi Block allocation, the network shall respond by sending a PACKET UPLINK ASSIGNMENT message 
(radio resources assignment on one or more PDCHs to be used by the mobile station for the TBF in EGPRS or GPRS 
TBF mode) or a PACKET ACCESS REJECT message to the mobile station on PACCH on the same PDCH on which 
the mobile station has sent the PACKET RESOURCE REQUEST message. 

On receipt of a PACKET RESOURCE REQUEST message requesting multiple uplink TBFs, the network shall respond 
by sending either a MULTIPLE TBF UPLINK ASSIGNMENT message or a PACKET ACCESS REJECT message to 
the mobile station on PACCH on the same PDCH on which the mobile station has sent the PACKET RESOURCE 
REQUEST message. These messages shall address (assign or reject) some or all of the resource requests in the 
PACKET RESOURCE REQUEST message. For the resource requests that have not been addressed by the first 
assignment or reject message, additional MULTIPLE TBF UPLINK ASSIGNMENT or PACKET ACCESS REJECT 
messages may be sent to the mobile station on the PACCH to which the mobile station has been assigned. 

If the received PACKET RESOURCE REQUEST message is indicating additional MS Radio Access Capabilities 
information available, the following additional requirements apply: 

- If the PACKET RESOURCE REQUEST message was scheduled with a Multi Block allocation of two blocks, 
the network shall respond by sending a PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK 
ASSIGNMENT message after reception of the ADDITIONAL MS RADIO ACCESS CAPABILITIES message. 

- If the PACKET RESOURCE REQUEST message was scheduled with a Single Block allocation or with a Multi 
Block allocation of only one block, the network shall respond upon receipt by sending a 

PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK ASSIGNMENT message. When assigning 
one or more EGPRS TBFs, the network may request additional information about radio access capabilities of the 
mobile station on one or several frequency bands within the PACKET UPLINK ASSIGNMENT or MULTIPLE 
TBF UPLINK ASSIGNMENT message; the list of frequency bands is ordered by the network starting with the 
most important and ending with the least important one. The mobile station shall provide the network with its 
radio access capabilities for the frequency bands it supports, in the same priority order as the one specified by the 
network, by sending an ADDITIONAL MS RADIO ACCESS CAPABILITIES message within the first radio 
block allocated to the mobile station on the assigned PDCH(s). When constructing the ADDITIONAL MS 
RADIO ACCESS CAPABILITIES message, the mobile station shall take care that this message fits in one 
uplink radio block. If the mobile station does not support any frequency band requested by the network, it shall 
report its radio access capabilities for the BCCH frequency band. 

In case the ADDITIONAL MS RADIO ACCESS CAPABILITIES message is not received correctly, the network may 
either: 

- send a PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK ASSIGNMENT message assigning 
radio resources on one or more PDCHs to be used by the mobile station for the TBF(s) in EGPRS or GPRS TBF 
mode, based on the information the network has got, or let unchanged the already assigned PDCH(s); 

send a PACKET UPLINK ASSIGNMENT message assigning (or reassigning) radio resources on one or more 
PDCHs to be used by the mobile station for the TBF(s) in EGPRS TBF mode and request a retransmission of the 
ADDITIONAL MS RADIO ACCESS CAPABILITIES message. 

In addition, in case the ADDITIONAL MS RADIO ACCESS CAPABILITIES message scheduled with a Multi Block 
allocation of two blocks is not received correctly, the network may either: 

- send a PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK ASSIGNMENT message including a 
Multi Block allocation struct (allocating only one block) requesting a retransmission of the ADDITIONAL MS 
RADIO ACCESS CAPABILITIES message; 

- send a PACKET ACCESS REJECT message to the mobile station. 

On receipt of a PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK ASSIGNMENT message where no 
TBF starting time is specified, the mobile station shall switch to the assigned PDCHs, stop T3168 for each resource 
request that is assigned a TBF in the PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK 
ASSIGNMENT message, and start timer T3164 for each allocated TBF if dynamic or extended dynamic allocation is 
assigned. If a TBF starting time is specified the mobile station shall stop T3168 for each resource request assigned a 
TBF and wait until the indicated TBF starting time before switching to the assigned PDCHs and starting T3164 for each 
allocated TBF. 
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At sending of the first RLC data block on a TBF, the mobile station shall stop timer T3164 for that TBF. 

The mobile station may use information received on PBCCH, BCCH or a previous assignment message to decode the 
frequency parameters contained in the assignment message. If the mobile station detects an invalid Frequency 
Parameters information element in the assignment message, it shall abort the procedure, if required initiate a partial 
acquisition of PBCCH or BCCH information, and may then re-initiate the access on the PRACH. 

On receipt of a PACKET ACCESS REJECT message that contains a Reject structure addressed to the mobile station, 
the mobile station shall stop timer T3168 and indicate a packet access failure to upper layer for each resource request 
which is rejected in the Reject structure. 

If the PACKET ACCESS REJECT message contains a WAIT_INDICATION field in a Reject structure addressed to 
the mobile station, the mobile station shall start timer T3172 with the indicated value (Wait Indication). The mobile 
station is not allowed to make a new attempt for packet access in the same cell until timer T3172 expires, but may 
attempt packet access in another cell after successful cell reselection. 

When the network receives a Packet Flow Identifier (PFI) from the mobile then the network should handle the uplink 
transfer according the associated aggregate BSS QoS profile (ABQP). The Peak Throughput specified in the associated 
ABQP, available in the network, supersedes the Peak Throughput specified by the Channel Request Description IE. 

7.1 .3.3 Contention resolution at two phase access 

The contention resolution is completed on the network side when the network receives a TLLI value identifying the 
mobile station, as part of the contention resolution procedure on the TBF. 

The contention resolution is completed on the mobile station side when the mobile station receives a 
PACKET UPLINK ASSIGNMENT , MULTIPLE TBF UPLINK ASSIGNMENT or PACKET ACCESS REJECT 
message with the same TLLI as the mobile station has included in the PACKET RESOURCE REQUEST and 
ADDITIONAL MS RADIO ACCESS CAPABILITIES messages that addresses at least one TBF for which resources 
were requested in the PACKET RESOURCE REQUEST message. 

If the mobile station receives an assignment for its single uplink TBF request, it shall then stop timer T3 168. It 
does not include its TLLI in any RLC data block. 

If the mobile station receives an assignment for at least one TBF of a multiple uplink TBF request, it shall then 
stop timer T3188 and the instance of T3168 which was started for the assigned TBF. It does not include its TLLI 
in any RLC data block. 

After contention resolution is successfully completed on the mobile station side, if the mobile station requested multiple 
uplink TBFs and an instance of timer T3168 expires, TBF establishment for the corresponding upper layer PDU has 
failed. The mobile station shall reinitiate a resource request for that upper layer PDU using the procedures described in 
sub-clauses 8.1.1.1.2a and 8.1.1.1.2b. 

The contention resolution has failed on the mobile station side when the mobile station does not receive a 
PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK ASSIGNMENT message with its TLLI assigning at 
least one TBF for which resources were requested before expiry of timer T3168 (single uplink TBF requested) or T3188 
(multiple uplink TBFs requested). The mobile station shall then reinitiate the packet access procedure unless the packet 
access procedure has already been attempted four times. In that case, TBF failure has occurred and an RLC/MAC error 
should be reported to the higher layer for each of the TBFs for which resources were requested. 

7.1 .3.4 Two phase packet access completion 

The two phase packet access procedure is completed upon a successful contention resolution. The mobile station has 
entered the packet transfer mode or MAC-Shared state. 

7.1.3.5 Timing Advance 

If a Timing Advance Index is included in the PACKET UPLINK ASSIGNMENT message, the mobile station shall use 
the continuous timing advance procedure, using its allocation on PTCCH (see 3GPP TS 45.010). Otherwise, the 
continuous timing advance procedure shall not be used. 

For the case where a TIMING_ADVANCE_VALUE field is not provided in the assignment message, the mobile 
station shall use its previous timing advance (either assigned in the previous IMMEDIATE ASSIGNMENT message 
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received on AGCH or in the previous PACKET UPLINK ASSIGNMENT message received on PAGCH or got through 
the continuous timing advance procedure). 

Otherwise, the mobile station is not allowed to send normal bursts on the uplink until it receives a valid timing advance 
either through the continuous timing advance procedure or in a PACKET POWER CONTROL/TIMING ADVANCE 

message. 

7.1 .4 Abnormal cases 

If a failure occurs on the mobile station side of the new TBF before mobile station has successfully entered the packet 
transfer mode, the newly reserved resources are released; the subsequent behaviour of the mobile station depends on the 
type of failure and previous actions. 

If the failure is due to a TLLI mismatch, or to the expiry of timers T3 166 or T3 168, or to the fact that the counter 
N3104 reaches its maximum value in the contention resolution procedure, and repetition as described in sub- 
clauses 7.1.2.3, 7.1.3.2.1 or 7.1.3.3 has been performed, the mobile station shall remain in packet idle mode, 
notify higher layer (TBF establishment failure), transactions in progress shall be aborted and cell reselection 
continued, unless the failure takes place during a RR-cell change order procedure, in which case the mobile 
behaviour shall be as described in the Abnormal cases of the RR-Network Commanded Cell Change Order 
Procedure in 3GPP TS 44.018. 

If the mobile station has been assigned more PDCHs than it supports according to its MS multislot class, the 
mobile station shall reinitiate the packet access procedure unless the packet access procedure has already been 
attempted four times. In that case, TBF failure has occurred. 

- If the information in the PACKET UPLINK ASSIGNMENT message does not properly specify an uplink PDCH 
or violates the mobile station's multislot capabilities, the mobile station shall reinitiate the packet access 
procedure unless the packet access procedure has already been attempted four times. In that case, TBF failure 
has occurred. 

- If the information in the MULTIPLE TBF UPLINK ASSIGNMENT message does not properly specify an 
uplink PDCH or violates the mobile station's multislot capabilities, the mobile station shall reinitiate the packet 
access procedure for each of the TBFs for which there is an error unless the procedure has already been 
attempted 4 times for the TBF. In that case, TBF failure has occurred. 

- If the MULTIPLE TBF UPLINK ASSIGNMENT message contains assignments including PFI values for which 
no TBF was requested, the mobile station shall not act upon these assignments. The mobile station shall act upon 
the valid assignments contained in the received message. 

- If the MULTIPLE TBF UPLINK ASSIGNMENT message contains assignments such that more than one PFI 
value has been assigned to the same TFI, then TBF failure has occurred for the requests containing each of those 
PFI values. 

If the PACKET ACCESS REJECT message incorrectly specifies a Reject structure and A/Gb mode Reject 
structure for this mobile station, or contains one or more PFIs in the A/Gb mode Reject structure for which no 
TBF was requested, the mobile station shall ignore this message. 

If the mobile station has been assigned a TBF in EGPRS mode and the MS does not support EGPRS, or has been 
assigned an MCS (e.g. 8-PSK in the Uplink) that the MS does not support, the MS shall return to packet idle 
mode and notify higher layers (TBF establishment failure). 

On expiry of timer T3 164, the mobile station shall reinitiate the packet access procedure for the corresponding 
TBF unless the packet access procedure has already been attempted four times for this TBF, in which case the 
mobile station shall notify higher layers of TBF establishment failure. If the mobile station has no remaining 
TBFs allocated it shall return to packet idle mode and notify higher layers (TBF establishment failure). 

If the failure is due to any other reason, the mobile station shall return to packet idle mode, notify higher layer 
(TBF establishment failure), transactions in progress shall be aborted and cell reselection continues. 

7.2 TBF establishment initiated by the network on PCCCH 

The purpose of network initiated TBF establishment is to establish a TBF to support the transfer of upper layer PDUs in 
the direction from the network to the mobile station. The procedure may be entered when the mobile station is in packet 
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idle mode. Network initiated TBF establishment can also be done on PACCH if a TBF for transfer of upper layer PDUs 
in the direction from the mobile station to the network is already established (sub-clause 8.1.1.1.3). 

If the mobile station is in dedicated mode and both the network and the mobile station support DTM, the establishment 
of a TBF shall be performed by the DTM assignment procedures on the main DCCH, as defined in 3GPP TS 44.018. 

7.2.1 Entering the packet transfer mode 

The procedure is triggered by a request from upper layers on the network side to transfer an upper layer PDU to a 
mobile station in packet idle mode. The request from upper layers specifies an optional priority level, a QoS profile 
including the requested RLC mode, optional DRX parameters, an optional IMSI and an optional MS Radio Access 
Capability, multislot class and mobile classmark to be associated with the packet transfer. The request is implicit when 
receiving an upper layer PDU to a mobile station not already having any assigned radio resources. Upon such a request, 
the network shall initiate a packet downlink assignment procedure as defined in sub-clause 7.2.1.1. The BSS may order 
its preferred RLC mode when establishing a downlink TBF, independently of the RLC mode signalled from upper 
layers, 

7.2.1 .1 Packet downlink assignment procedure 

The network may assign a radio resource on one or more PDCHs to be used for the TBF. The amount of radio resource 
to be reserved is a network dependent choice. 

The allocated radio resource is assigned to the mobile station in a PACKET DOWNLINK ASSIGNMENT message to 
the mobile station. The PACKET DOWNLINK ASSIGNMENT message is transmitted on the PCCCH timeslot 
corresponding to the PCCCH group the mobile station belongs to. The appropriate PCCCH group is calculated from the 
IMSI (see 3GPP TS 45.002). The behaviour of the network when the IMSI is not provided by the upper layers is 
implementation dependent for the calculation of the PCCCH group where the PACKET DOWNLINK ASSIGNMENT 
message has to be sent. If the mobile station is in non-DRX mode or if the IMSI or the DRX parameters are not 
provided by the upper layers, there is no further restriction on what part of the downlink PCCCH timeslot this 
PACKET DOWNLINK ASSIGNMENT message can be sent, provided that this part corresponds to one or more blocks 
where paging may appear. If the mobile station applies DRX, this message shall be sent in one or more PCCCH 
block(s) corresponding to a paging group determined for the mobile station in packet idle mode or MAC -Idle state (see 
3GPP TS 45.002). The multislot capabilities of the mobile station shall be considered. 

Initial timing advance can be provided in the PACKET DOWNLINK ASSIGNMENT message as Timing Advance 
Value field. In case valid timing advance for the mobile station is not available, the network may use one of the 
following two methods to trigger the mobile station to transmit a PACKET CONTROL ACKNOWLEDGEMENT 

message: 

- if the PACKET DOWNLINK ASSIGNMENT message is not segmented and the CONTROL_ACK_TYPE 
parameter in the System Information indicates acknowledgement is access bursts, the network may set the poll 
bit in the PACKET DOWNLINK ASSIGNMENT message. 

- if the PACKET DOWNLINK ASSIGNMENT message is segmented or the CONTROL. ACK_TYPE parameter 
in the System Information does not indicate acknowledgement is access bursts, the network may send PACKET 
POLLING REQUEST message with TYPE_OF_ACK parameter set to access bursts (see sub-clause 11.2.12). 

The mobile station shall then send the PACKET CONTROL ACKNOWLEDGEMENT message as four access bursts 
in the reserved uplink radio block specified by the RRBP field as defined in sub-clause 10.4.5.The reserved block is 
considered as a one block PACCH allocation. The PACKET CONTROL ACKNOWLEDGEMENT message is used to 
derive the timing advance. 

Thereafter, either the timing advance in the mobile station is updated with a PACKET POWER CONTROL /TIMING 
ADVANCE message or a continuous timing advance procedure is used. If a Timing Advance Index is included in the 
assignment message, the mobile station shall use the continuous timing advance procedure, using its allocation on 
PTCCH (see 3GPP TS 45.010). Otherwise the continuous timing advance procedure shall not be used. For the case 
where Timing Advance Value is not provided in the assignment message, the mobile station is not allowed to send 
normal bursts (e.g. PACKET DOWNLINKACK/NACK message) on the uplink until it receives a valid timing advance 
either through the continuous timing advance procedure or in a PACKET POWER CONTROL /TIMING ADVANCE 
message. 

The mobile station shall use information received on the PBCCH to decode the channel descriptions contained in the 
assignment. If frequency hopping is applied, the mobile station shall use the last CA received on PBCCH to decode the 
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Mobile Allocation. Alternatively, the network may provide a Mobile Allocation in the assignment. The radio resource is 
assigned to the mobile station in a PACKET DOWNLINK ASSIGNMENT message. On receipt of a 
PACKET DOWNLINK ASSIGNMENT message, the mobile station shall switch to the assigned PDCHs. 

A PACKET DOWNLINK ASSIGNMENT message may indicate an assignment starting time in the TBF Starting Time 
parameter. The mobile station shall monitor PCCCH until the point in time denoted by the TBF Starting Time. If the 
mobile station receives more than one PACKET DOWNLINK ASSIGNMENT message while it monitors the PCCCH, 
it shall act upon the most recently received message and shall ignore the previous message. 

When the PACKET DOWNLINK ASSIGNMENT message is received and after awaiting the point in time denoted by 
the TBF Starting Time, if such is indicated, the mobile station shall switch to the assigned PDCHs and start timer 
T3190. The timer T3190 is restarted when receiving the first valid RLC data block addressed to the mobile station. In 
EGPRS TBF mode T3190 is also restarted when receiving an erroneous RLC data block for which the header is 
correctly received and which addresses the mobile station. 

When the mobile station switches to the assigned PDCHs, it shall take the power control parameters received in the 
PACKET DOWNLINK ASSIGNMENT message into account, perform signal strength measurements and apply output 
power control procedures as they are defined for packet transfer mode or MAC-Shared state (see 3GPP TS 45.008). 

On expiry of timer T3 190, the mobile station shall abort the procedure and return to packet idle mode or MAC -Idle 
state. 

7.2.1 .2 Packet downlink assignment procedure completion 

The packet downlink assignment procedure is completed when the mobile station receives a valid RLC/MAC block. 
The mobile station has entered the packet transfer mode or MAC-Shared state. 

7.2.1 .3 Packet polling procedure 

The network may send to the mobile station a PACKET POLLING REQUEST message. If the MS has received a 
PACKET DOWNLINK ASSIGNMENT message with no starting time or with a starting time that has already elapsed, 
the PACKET POLLING REQUEST message shall be sent on PACCH. Otherwise the PACKET POLLING message 
shall be sent on PAGCH. The mobile station shall be addressed by its TLLI (A/Gb mode), G-RNTI (lu mode) or TFI. 

On receipt of a PACKET POLLING REQUEST message, the mobile station shall respond to the network with the 
PACKET CONTROL ACKNOWLEDGEMENT message in the reserved uplink radio block specified by the RRBP 
field as defined in sub-clause 10.4.5. The reserved block is considered as a one block PACCH allocation. 

7.2.2 Abnormal cases 

If a failure occurs on the mobile station side of the new TBF before mobile station has successfully entered the packet 
transfer mode or MAC-Shared state, the newly reserved resources are released; the subsequent behaviour of the mobile 
station depends on the type of failure and previous actions. 

If the mobile station has been assigned more PDCHs than it supports according to its MS multislot class, the 
mobile station shall return to packet idle mode or MAC -Idle state. 

If the mobile station has been assigned a TBF in EGPRS TBF mode and the MS does not support EGPRS, or has 
been assigned an MCS (e.g. 8-PSK in the uplink) that the MS does not support, the MS shall return to packet idle 
mode or MAC -Idle state and notify higher layers (TBF establishment failure) 

On expiry of timer T3 190, the mobile station shall return to packet idle mode or MAC-Idle state. 

If the failure is due to any other reason, the mobile station shall return to packet idle mode or MAC-Idle state and 
cell reselection continues. 
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7.3 Procedure for measurement report sending in packet idle 
mode 

The procedure for measurement report sending shall be initiated by the mobile station at expiry of the NC measurement 
report interval timer T3158. At expiry of the timer T3158 the mobile station shall restart the expired timer T3158, 
perform the measurements and initiate the packet access. 

The procedure for measurement report sending is initiated by the mobile station either on PCCCH (sub-clause 7.3.1) or, 
if a packet control channel not exists, on CCCH (sub-clause 7.3.2). 

If the mobile station initiates the establishment of an RR connection, the timer T3158 shall be stopped and no 
measurement reports shall be sent. When the RR connection is released and if the mobile station has not changed cell, 
the measurement reporting procedure shall be restarted. 

If a cell change has occurred during the RR connection, the measurements shall be cancelled until new NC orders have 
been received (see sub-clause 5.6). 

7.3.1 IVIeasurement report sending procedure initiated on PCCCH 

The packet access procedure is initiated by the RR entity in the mobile station as specified in sub-clauses 7.1.2.1 and 
7.1.2.2 but with access type "Single block without TBF establishment" indicated in the PACKET CHANNEL 
REQUEST message. In the following sub-clauses the procedure is only briefly summarised and special requirements 
are indicated. 

7.3.1 .1 On receipt of a PACKET CHANNEL REQUEST message 

On receipt of a PACKET CHANNEL REQUEST message with access type indicating 'Single block without TBF 
establishment', the network may allocate one radio block on an uplink PDCH. 

If uplink resources are not available, the network may reject the access request by sending a PACKET ACCESS 
REJECT message (see sub-clause 7.3.1.3). The network shall not respond to a packet access for measurement reporting 
by sending a PACKET QUEUING NOTIFICATION message. 

The radio resource is assigned to the mobile station in a PACKET UPLINK ASSIGNMENT message sent on any 
PAGCH on the same PCCCH on which the network has received the PACKET CHANNEL REQUEST message. The 
PACKET UPLINK ASSIGNMENT message shall include the following optional parameters: 

Power Control Parameters with timeslot allocation; 

- Frequency parameters; 

- TBF_STARTING_TIME indicating the frame number of the allocated block; 

- TIMING_ADVANCE_VALUE; 
Packet Request Referenc. 

7.3.1 .2 On receipt of a PACKET UPLINK ASSIGNMENT message 

When receiving a PACKET UPLINK ASSIGNMENT message the mobile station shall send either the 

PACKET MEASUREMENT REPORT message or the PACKET ENHANCED MEASUREMENT REPORT message 

in the allocated radio block on the assigned PDCH and immediately switch back to the PCCCH in non-DRX mode (see 

sub-clause 5.5.1.5). No TBF is established and the network shall not acknowledge the reception of the 

PACKET MEASUREMENT REPORT message or the PACKET ENHANCED MEASUREMENT REPORT message. 

The PACKET MEASUREMENT REPORT message shall contain the NC Measurement Report struct. 

If T3170 expires before a PACKET UPLINK ASSIGNMENT message is received, the packet access procedure is 
aborted, the transmission of the measurement report for that measurement period is cancelled, and the mobile station 
returns to packet idle mode or MAC-Idle state. 
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7.3.1 .3 On receipt of a PACKET ACCESS REJECT message 

The network may send to the mobile station a PACKET ACCESS REJECT message. 

The mobile station shall react to this as described in sub-clause 7.1.2.2.4 with the exception of the actions taken when 
either of the timers T3172 or T3162 expires. In this case, the measurement report initiating the packet access shall be 
discarded and the mobile station shall return to packet idle mode or MAC -Idle state. 

If the measurement report interval timer T3158 expires before any of the timers T3172 or T3162 expires, no new 
measurement shall be initiated but the timer T3158 shall be restarted. 

7.3.1.4 Abnormal cases 

If on the mobile station side timer T3 170 expires indicating unsuccessful channel request procedure or if the 
PACKET UPLINK ASSIGNMENT message contains faulty parameters, the mobile station shall abort the procedure 
and return to packet idle mode or MAC-Idle state. The measurement report initiating the packet access shall be 
discarded. 

If the mobile station receives either a PACKET QUEUING NOTIFICATION message or a PACKET POLLING 
REQUEST message, the mobile station shall abort the procedure and return to packet idle mode or MAC-Idle state. The 
measurement report initiating the packet access shall be discarded. 

7.3.2 Measurement report sending procedure initiated on CCCH 

For detailed description of the procedures following in this sub-clause, see 3GPP TS 44.018. The procedure is here only 
briefly summarised and special requirements are indicated. 

The packet access procedure is initiated by the RR entity in the mobile station. The mobile station sends a CHANNEL 
REQUEST message indicating 'Single block packet access' on RACH. The network shall then respond with either an 
IMMEDIATE ASSIGNMENT message granting a "single block access" on a PDCH or an IMMEDIATE 
ASSIGNMENT REJECT message (see 3GPP TS 44.018). 

If a PDCH block is assigned, the mobile station shall send either the PACKET MEASUREMENT REPORT message or 
the PACKET ENHANCED MEASUREMENT REPORT message in the allocated radio block on the assigned PDCH 
and then immediately switch back to the CCCH in non-DRX mode (see sub-clause 5.5.1.5). No TBF is established and 
the network shall not acknowledge the reception of the PACKET MEASUREMENT REPORT message or the 
PACKET ENHANCED MEASUREMENT REPORT message. 

The PACKET MEASUREMENT REPORT message shall contain the NC Measurement Report struct. 

On receipt of an IMMEDIATE ASSIGNMENT REJECT message the mobile station shall follow the procedure 
specified in 3GPP TS 44.018 sub-clause 'Packet access rejection' with the exception of the actions taken when either of 
the 3GPP TS 44.018 timers T3142 or T3146 expires. In this case, the measurement report initiating the packet access 
shall be discarded and the mobile station shall return to packet idle mode. 

If the measurement report interval timer T3158 expires before any of the 3GPP TS 44.018 timers T3142 or T3146 
expires, no new measurement shall be initiated but the timer T3158 shall be restarted. 

7.4 Cell Change Order procedures in Packet Idle mode 

For an individual mobile station in packet idle mode, the network may initiate the cell change order procedure either on 
PCCCH or, if a packet control channel does not exist, on CCCH. 

7.4.1 Cell Change Order procedure initiated on PCCCH 

The network may initiate the cell change order procedure by sending a PACKET CELL CHANGE ORDER message in 
a PCCCH block monitored by the mobile station. No TBF shall be established. 

The PACKET CELL CHANGE ORDER message contains: 

- The characteristics of the new cell that are necessary to identify it (i.e. BSIC + BCCH frequency); 
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The NC measurement parameters valid for the mobile station in the new cell (NETWORK_CONTROL_ORDER 
and optionally: NC_NON_DRX_PERIOD, NC_REPORTING_PERIOD_I and NC_REPORTING_PERIOD_T). 

For a multi-RAT mobile station, the PACKET CELL CHANGE ORDER message may contain information on a 3G 
target cell; in the case of UTRAN, the establishment of channel(s) and subsequent measurement reporting are defined in 
3GPPTS 25.33 L 

If the mobile station is not involved in an RR connection, upon receipt of the PACKET CELL CHANGE ORDER 
message, the mobile station shall stop all relevant RLC/MAC timers except for timers related to measurement reporting 
and start timer T3174. The mobile station shall then switch to the specified new cell and obey the relevant RLC/MAC 
procedures on this new cell. If a valid RRBP field was received in the PACKET CELL CHANGE ORDER message 
then the MS shall send a PACKET CONTROL ACKNOWLEDMENT message in the reserved uplink radio block 
specified by the RRBP field before switching to the new cell. If the timers related to measurement reporting expire 
while the reselection procedure has not yet been completed, these timers shall be restarted so that the mobile station 
resumes the measurement reporting procedures once camped on the new cell. A UTRAN capable mobile station ordered 
to a UTRAN cell shall obey the PACKET CELL CHANGE ORDER message irrespective of whether the target cell is 
known or not known (see 3GPP TS 25.133 and 3GPP TS 25.123). 

If the mobile station is involved in an RR connection, the mobile station shall ignore the PACKET CELL CHANGE 
ORDER message. 

The procedure for completion of the cell change order is defined in sub-clause 8.4.1 and abnormal procedures are 
defined in sub-clause 8.4.2. 

7.4.2 Cell Change Order procedure initiated on CCCH 

The network may initiate the cell change order procedure by sending an IMMEDIATE ASSIGNMENT message for 
single block assignment in a CCCH block monitored by the mobile station. No TBF shall be established. The single 
block assignment procedure is specified in 3GPP TS 44.018. 

The network shall then send the PACKET CELL CHANGE ORDER message in the assigned downlink block to the 
mobile station. The PACKET CELL CHANGE ORDER message contains: 

the characteristics of the new cell that are necessary to identify it (i.e. BSIC + BCCH frequency); 

the NC measurement parameters valid for the mobile station in the new cell (NETWORK_CONTROL_ORDER 
and optionally: NC_NON_DRX_PERIOD, NC_REPORTING_PERIOD_I and NC_REPORTING_PERIOD_T). 

For a multi-RAT mobile station, the PACKET CELL CHANGE ORDER message may contain information on a 3G 
target cell; in the case of UTRAN, the establishment of channel(s) and subsequent measurement reporting are defined in 
3GPPTS 25.331. 

Upon receipt of the PACKET CELL CHANGE ORDER message, the mobile station shall stop all relevant RLC/MAC 
timers except for timers related to measurement reporting and start timer T3174. The mobile station shall then switch to 
the specified new cell and obey the relevant RLC/MAC procedures on this new cell. If a valid RRBP field was received 
in the PACKET CELL CHANGE ORDER message then the MS shall send a PACKET CONTROL 
ACKNOWLEDMENT message in the reserved uplink radio block specified by the RRBP field before switching to the 
new cell. If the timers related to measurement reporting expire while the reselection procedure has not yet been 
completed, these timers shall be restarted so that the mobile station resumes the measurement reporting procedures once 
camped on the new cell. A UTRAN capable mobile station ordered to a UTRAN cell shall obey the PACKET CELL 
CHANGE ORDER message irrespective of whether or not the target cell is known (see 3GPP TS 25.133 and 
3GPPTS 25.123). 

The procedure for completion of the cell change order is defined in sub-clause 8.4.1 and abnormal procedures are 
defined in sub-clause 8.4.2. 

7.5 Measurement Order procedures in Packet Idle mode 

To send the NC Measurement order to an individual mobile station in packet idle mode, the network may establish a 
connection either on PCCCH or, if a packet control channel does not exist, on CCCH. 
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7.5.1 Measurement Order procedures initiated on PCCCH 

The network may initiate the measurement order procedure by sending a PACKET MEASUREMENT ORDER 
message in a PCCCH block monitored by the mobile station. The PACKET MEASUREMENT ORDER message 
overrides a broadcast PSI5 message. If the PACKET MEASUREMENT ORDER message contains multiple instances, 
the network shall send all instances to the mobile station. 

The PACKET MEASUREMENT ORDER message may contain the following optional Measurement order 
parameters:- TLLI (shall be included in A/Gb mode); 

G-RNTI (shall be included in lu mode); 

- Enhanced measurement parameters. 

Upon receipt of the PACKET MEASUREMENT ORDER message, the mobile station shall store the Measurement 
order parameters . The mobile station shall obey the NETWORK_CONTROL_ORDER as specified in 3GPP TS 45.008 
and in sub-clause 5.6. 

7.5.2 Measurement Order procedures initiated on CCCH 

The network may initiate the measurement order procedure by allocating a single block in an IMMEDIATE 
ASSIGNMENT message sent to the mobile station on a CCCH block in the same way as specified in sub-clause 7.4.2. 

The network shall then send the PACKET MEASUREMENT ORDER message in the assigned downhnk block to the 
mobile station. The PACKET MEASUREMENT ORDER message overrides a broadcast PSI5 message. If the 
PACKET MEASUREMENT ORDER message contains multiple instances, the network has to repeat the complete 
procedure with new assignment for each instance of the message. 

The PACKET MEASUREMENT ORDER message may contain the following optional Measurement order parameters: 

TLLI (shall be included); 

- NC Measurement Parameters (NETWORK_CONTROL_ORDER; NC_NON_DRX_PERIOD; 
NC_REPORTING_PERIOD_I; NC_REPORTING_PERIOD_T; NC_FREQUENCY_LIST); 

Enhanced measurement parameters. 

Upon receipt of the PACKET MEASUREMENT ORDER message, the mobile station shall store the Measurement 
order parameters . The mobile station shall obey the NETWORK_CONTROL_ORDER as specified in 3GPP TS 45.008 
and in sub-clause 5.6. 



7.6 Packet Pause procedure 



This procedure enables the network to pause GPRS services packet flow for a mobile station with non-GSM capabilities 
in the downlink direction. The procedure is initiated by the mobile station either on a PCCCH (sub-clause 7.6. 1) or, if a 
packet control channel does not exist, on a CCCH (sub-clause 7.6.2). 

7.6.1 Pacl^et pause procedure initiated on PCCCH 

The packet access procedure is initiated by the RR entity in the mobile station as specified in sub-clauses 7.1.2.1 and 
7.1.2.2 but with access type 'Single block without TBF estabhshment' indicated in the PACKET CHANNEL 
REQUEST message. 

7.6.1 .1 On receipt of a PACKET CHANNEL REQUEST message 

On receipt of a PACKET CHANNEL REQUEST message with access type indicating "Single block without TBF 
establishment", the network may allocate one radio block on an uplink PDCH. 

If uplink resources are not available, the network may reject the access request by sending a PACKET ACCESS 
REJECT message (see sub-clause 7.6.1.3). The network shall not respond by sending a PACKET QUEUING 
NOTIFICATION message. 
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The radio resource is assigned to the mobile station in a PACKET UPLINK ASSIGNMENT message sent on any 
PAGCH on the same PCCCH on which the network has received the PACKET CHANNEL REQUEST message. The 
PACKET UPLINK ASSIGNMENT message shall include the following optional parameters: 

Power Control Parameters with timeslot allocation; 

- Frequency parameters; 

- TBF_STARTING_TIME indicating the frame number of the allocated block; 

- TIMING_ADVANCE_VALUE; 
Packet Request Reference. 

7.6.1 .2 On receipt of a PACKET UPLINK ASSIGNMENT message 

When receiving a PACKET UPLINK ASSIGNMENT message the mobile station shall send PACKET PAUSE in the 
allocated radio block on the assigned PDCH. The mobile station shall stop timer T3204. No TBF is established and the 
network shall not acknowledge the reception of the PACKET PAUSE message. 

If timer T3204 expires before a PACKET UPLINK ASSIGNMENT message is received, the packet pause procedure is 
aborted. 

7.6.1 .3 On receipt of a PACKET ACCESS REJECT message 

The network may send to the mobile station a PACKET ACCESS REJECT message. The mobile station shall react by 
aborting the packet pause procedure and stopping timer T3204. 

7.6.1.4 Abnormal cases 

If on the mobile station side timer T3204 expires indicating unsuccessful channel request procedure or if the 
PACKET UPLINK ASSIGNMENT message contains faulty parameters, the mobile station shall abort the packet pause 
procedure. 

If the mobile station receives either a PACKET QUEUING NOTIFICATION message or a PACKET POLLING 
REQUEST message, the mobile station shall abort the packet pause procedure. 

7.6.2 Packet pause procedure initiated on CCCH 

For a description of the procedure, see 3GPP TS 44.018. 

7.7 MBMS packet access and establishment procedures 
7.7.1 MBMS packet access procedure 
7.7.1.1 General 

This procedure enables the network to count the number of mobile stations in a cell that want to receive an MBMS 
session. If the procedure is initiated by the mobile station as a response to an MBMS notification, which contains uplink 
resource description for an MPRACH, the procedure shall be initiated on that MPRACH (sub-clause 7.7.1.4). 
Otherwise the procedure is initiated by the mobile station either on a PCCCH (sub-clause 7.7. 1 .2) or, if a packet control 
channel is not allocated in the cell, on a CCCH (sub-clause 7.7.1.3). 

The procedure may be initiated by the mobile station either: 

as a response to an MBMS notification where counting is requested; or 

in the new cell after cell reselection during an ongoing MBMS session, if MBMS is supported by the network in 
the new cell; or 
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when a request is received from upper layer in the mobile station, if MBMS is supported by the network in the 
cell; or 

after timeout when waiting for an RLC block for this session. 

NOTE: The mobile station shall not initiate an MBMS packet access procedure in a new cell after cell reselection 
if the mobile station already has information about the location and identifier of the MBMS radio bearer 
relevant to the ongoing MBMS session in that new cell and it contains no uplink feedback channel. 

A mobile station that is IMSI attached (GPRS class A or B mode of operation) shall respond to a PACKET PAGING 
REQUEST message indicating an RR connection establishment or TBF establishment. For that purpose, the mobile 
station shall abort the MBMS packet access procedure, according to the conditions stated in sub-clause 6.1.4. 

If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message, it shall abort the MBMS packet 
access procedure and respond to the PACKET DOWNLINK ASSIGNMENT message (see sub-clause 7.2.1) 

7.7.1 .2 MBMS packet access procedure on PCCCH 

7.7.1 .2.0 Initiation of the MBMS packet access procedure 

The packet access procedure for an MBMS session is initiated by the mobile station on PCCCH, as specified in sub- 
clauses 7.1.2.1 with access type "Single block MBMS access" indicated in the PACKET CHANNEL REQUEST 

message. 

7.7.1 .2.1 On receipt of a PACKET CHANNEL REQUEST message 

On receipt of a PACKET CHANNEL REQUEST message with access type indicating "Single block MBMS access", 
the network may either allocate one radio block on an uplink PDCH, as specified in sub-clause 7.1.2.1 or, if uplink 
resources are not available, reject the access request by sending a PACKET ACCESS REJECT message (see sub-clause 
7.7.1.2.3). 

The radio resource is assigned to the mobile station in a PACKET UPLINK ASSIGNMENT message sent on any 
PAGCH on the same PCCCH on which the network has received the PACKET CHANNEL REQUEST message. The 
PACKET UPLINK ASSIGNMENT message shall include the following optional parameters: 

Power Control Parameters with timeslot allocation; 

- Frequency parameters; 

- TBF_STARTING_TIME indicating the frame number of the allocated block; 

- TIMING_ADVANCE_VALUE; 
Packet Request Reference. 

7.7.1 .2.2 On receipt of a PACKET UPLINK ASSIGNMENT message 

When receiving a PACKET UPLINK ASSIGNMENT message, corresponding to one of its 3 last PACKET 
CHANNEL REQUEST messages, the mobile station shall send the MBMS SERVICE REQUEST message in the 
allocated radio block on the assigned PDCH and then start timer T3214.While timer T3214 is running the mobile station 
shall accept reception of repeated PACKET UPLINK ASSIGNMENT messages, on any PAGCH on the same PCCCH 
on which the mobile station has sent the PACKET CHANNEL REQUEST message, and re-send the MBMS SERVICE 
REQUEST in the allocated block on the assigned PDCH and restart the timer T3214. 

At expiry of timer T3214, a mobile station in packet idle mode or MAC -Idle state shall return to DRX mode. No radio 
bearer will be established in the cell for the concerned MBMS session. A mobile station in broadcast/multicast receive 
mode shall remain in broadcast/multicast receive mode. 

7.7.1 .2.3 On receipt of a PACKET ACCESS REJECT message 

The network may send a PACKET ACCESS REJECT message to the mobile station in response to a PACKET 
CHANNEL REQUEST message. The mobile station shall then react as described in sub-clause 7.1.2.2.4. 
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7.7.1 .2.4 On receipt of an MBMS ASSIGNMENT message 

When the mobile station receives an MBMS ASSIGNMENT message for an MBMS session, it shall stop any ongoing 
packet access procedure for that MBMS session and proceed according to sub-clause 7.7.2.2. 

7.7.1.2.5 Abnormal cases 

If the mobile station receives a PACKET UPLINK ASSIGNMENT message that contains faulty parameters, the mobile 
station shall abort the MBMS packet access procedure. 

7.7.1 .3 MBMS packet access procedure on CCCH 

For a description of the procedure, see 3GPP TS 44.018. 

7.7.1 .4 MBMS packet access procedure on MPRACH 

7.7.1 .4.1 Initiation of the MBMS packet access procedure on MPRACH 

The mobile station initiates the MBMS packet access procedure on MPRACH by sending an MPRACH PACKET 
CHANNEL REQUEST message (see sub-clause 1 1.2.5c) with access type "Single block MBMS access" on the 
MPRACH. 

The mobile station shall determine the control parameters from the MPRACH control parameters included in the 
MBMS notification, if present. If an MPRACH control parameter is not available, the last received corresponding 
control parameter for the PRACH, if PCCCH is present, shall be used; otherwise the last received corresponding control 
parameter for the RACH shall be used. 

At sending of the first MPRACH PACKET CHANNEL REQUEST message, the mobile station shall store the value for 
the Retry (R) bit to be transmitted in all the subsequent MAC headers as 'MS sent channel request message once'. If a 
second MPRACH PACKET CHANNEL REQUEST message is sent, the mobile station shall change the value for the 
Retry (R) bit to 'MS sent channel request message once or more'. 

While waiting for a response to the MPRACH PACKET CHANNEL REQUEST message the mobile station shall 
continue to monitor the CCCH/PCCCH (whichever is applicable) corresponding to its 

CCCH_GROUP/PCCCH_GROUP. The mobile station shall perform signal strength measurements as they are defined 
for packet idle mode, see 3GPP TS 45.008. 

A mobile station that is IMSI attached (GPRS class A or B mode of operation) shall respond to a PACKET PAGING 
REQUEST message indicating an RR connection establishment. For that purpose, the mobile station may abort the 
packet access procedure, according to the conditions stated in sub-clause 6.1.4. The mobile station shall not respond to a 
PACKET PAGING REQUEST message indicating TBF establishment. 

A mobile station that is not IMSI attached (GPRS class C mode of operation) shall not respond to any type of PACKET 
PAGING REQUEST messages during the packet access procedure, it shall only decode the PERSISTENCE_LEVEL 
parameter, if that is included in the message. 

7.7.1 .4.1 .1 Access persistence control on MPRACH 

The mobile station shall make maximally M + 1 attempts to send an MPRACH PACKET CHANNEL REQUEST 

message. 

The mobile station shall use the control parameters determined by the procedure described in sub-clause 7.7.14.1: 

- MAX_RETRANS; 

- PERSISTENCE_LEVEL, which consists of the PERSISTENCE_LEVEL P e {0, 1, ...14, 16}. If the control 
parameters does not contain the PERSISTENCE_LEVEL parameter, this shall be interpreted as if P = 0; 

- S; 

- TX INT. 
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The mobile station shall start timer T3186 at the beginning of the MPRACH Packet Access Procedure. At expiry of 
timer T3186, the packet access procedure shall be aborted, packet access failure shall be indicated to upper layers and 
the mobile station shall return to packet idle mode or MAC -Idle state. 

The first attempt to send an MPRACH PACKET CHANNEL REQUEST may be initiated at the first available 
MPRACH block on the indicated PDCH. The mobile station shall choose one of the four TDMA frames within the 
selected MPRACH block randomly with a uniform probability distribution. 

For each attempt, the mobile station shall draw a random value R with uniform probability distribution in the set 

{0, 1, ..., 15}. The mobile station is allowed to transmit an MPRACH PACKET CHANNEL REQUEST message if P is 

less or equal to R. 

After each attempt, the S and T parameters are used to determine the next TDMA frame in which it may be allowed to 
make a successive attempt. The number of TDMA frames, belonging to the MPRACH on the indicated PDCH, between 
two successive attempts to send an MPRACH PACKET CHANNEL REQUEST message, excluding the TDMA frames 
potentially containing the messages themselves, is a random value drawn for each transmission, with uniform 
probability distribution, in the set {S, S + 1, ..., S + T - 1 }; 

Here: 

M is the value of the parameter MAX_RETRANS; 

T is the value of the parameter TX_INT; 

S is the value of the parameter S. 

Having made M + 1 attempts to send an MPRACH PACKET CHANNEL REQUEST message, the mobile station shall 
stop timer T3186 and start timer T3170. At expiry of timer T3170, the packet access procedure shall be aborted, a 
random access failure shall be indicated to upper layer and the mobile station shall perform autonomous cell re-selection 
according to 3GPP TS 43.022. 

If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message while it is waiting for a response to an 
MPRACH PACKET CHANNEL REQUEST message, it shall abort the MBMS packet access procedure on MPRACH 
and respond to the PACKET DOWNLINK ASSIGNMENT message (see sub-clause 7.2.1). 

7.7.1 .4.2 On receipt of an MPRACH PACKET CHANNEL REQUEST 

On receipt of an MPRACH PACKET CHANNEL REQUEST message with access type indicating "Single block 
MBMS access", the network shall either allocate one radio block on an uplink PDCH by sending a PACKET UPLINK 
ASSIGNMENT message on the downlink PDCH corresponding to the uplink PDCH where the MPRACH is allocated 
or, if uplink resources are not available, reject the access request by sending a PACKET ACCESS REJECT message on 
the same downlink PDCH (see sub-clause 7.7.1.4.3). 

The PACKET UPLINK ASSIGNMENT message shall include the optional parameters: 

Power Control Parameters with timeslot allocation; 

- Frequency parameters; 

- TBF_STARTING_TIME indicating the frame number of the allocated block; 

- TIMING_ADVANCE_VALUE; 
Packet Request Reference. 

7.7.1 .4.3 On receipt of a PACKET ACCESS REJECT message 

The network may, as response to an MPRACH PACKET CHANNEL REQUEST message, send to the mobile station a 
PACKET ACCESS REJECT message on the downhnk PDCH corresponding to the uplink PDCH where the MPRACH 
is allocated. This message contains the request reference with time of reception of the MPRACH PACKET CHANNEL 
REQUEST message and optionally a WAIT_INDICATION field in the Reject structure of the PACKET ACCESS 
REJECT message. 
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On receipt of a PACKET ACCESS REJECT message containing a Reject structure addressed to the mobile station, 
where the Packet Request Reference in the Reject structure corresponds to one of its 3 last MPRACH PACKET 
CHANNEL REQUEST messages: 

- The mobile station shall stop timer T3 186, stop sending MPRACH PACKET CHANNEL REQUEST messages, 
start timer T3172 with the value indicated in the WAITJNDICATION field, start timer T3170 if it has not 
already been started and listen to the downlink PCCCH until timer T3170 expires. During this time, the mobile 
station shall ignore additional PACKET ACCESS REJECT messages. During this time, on reception of any 
PACKET UPLINK ASSIGNMENT message corresponding to any other of its 3 last MPRACH PACKET 
CHANNEL REQUEST messages, the mobile station shall stop timers T3170 and T3172 if running, and follow 
the procedure defined in sub-clause 7.1.2.2.1b. 

- If no PACKET UPLINK ASSIGNMENT message is received before expiration of timer T3 170, the mobile 
station shall indicate a packet access failure to upper layer and return to packet idle mode (listening to its paging 
channel). As an option the mobile station may stop timer T3170, indicate a packet access failure to upper layer 
and return to packet idle mode as soon as it has received responses from the network on all or, in case more than 
3 were sent, the last 3 of its MPRACH PACKET CHANNEL REQUEST messages. If the mobile station is 
already engaged in a parallel broadcast/multicast session the mobile station shall remain in broadcast/multicast 
receive mode. 

If an erroneous PACKET UPLINK ASSIGNMENT message (e.g. the mobile station has been assigned more 
PDCHs than it supports according to its multislot class) addressed to the mobile station is received before 
expiration of timer T3170, the mobile station shall stop T3170 and act as stated in sub-clause 7.1.4. 

- If the mobile station receives a PACKET DOWNLINK ASSIGNMENT message, it shall stop timer T3 170 if 
running and respond to the PACKET DOWNLINK ASSIGNMENT message (see sub-clause 7.2.1). 

The mobile station is not allowed to make a new attempt for packet access in the same cell until timer T3172 
expires, but may attempt packet access in another cell after successful cell reselection for radio conditions 
reasons (see 3GPP TS 45.008). InA/Gb mode, a mobile station that is IMSI attached (GPRS class A or B mode 
of operation) may attempt to enter the dedicated mode in the same cell before timer T3172 has expired. During 
the time T3172 is running, the mobile station shall ignore all received PACKET PAGING REQUEST messages 
except paging request to trigger RR connection establishment. 

The value of the WAITJNDICATION field (i.e. timer T3 172) relates to the cell from which it was received. 

7.7.1 .4.4 On receipt of a PACKET UPLINK ASSIGNMENT message 

On receipt of a PACKET UPLINK ASSIGNMENT message corresponding to one of its 3 last MPRACH PACKET 
CHANNEL REQUEST messages the mobile station shall stop timers T3186 and T3170 if running and stop sending 
MPRACH PACKET CHANNEL REQUEST messages. The mobile station shall send the MBMS SERVICE 
REQUEST message in the allocated radio block on the assigned PDCH and then start timer T3214. While timer T3214 
is running the mobile station shall accept reception of repeated PACKET UPLINK ASSIGNMENT messages, on the 
downlink PDCH corresponding to the uplink PDCH where the MPRACH is allocated, and re-send the MBMS 
SERVICE REQUEST in the allocated block on the assigned PDCH and restart the timer T3214. 

At expiry of timer T3214, a mobile station in packet idle mode or MAC-Idle state shall return to DRX mode and shall 
consider the MBMS radio bearer as not established in the cell for the concerned MBMS session. A mobile station in 
broadcast/multicast receive mode shall remain in broadcast/multicast receive mode. 

7.7.1 .4.5 On receipt of an MBMS ASSIGNMENT message 

When the mobile station receives an MBMS ASSIGNMENT message for an MBMS session, it shall stop any ongoing 
packet access procedure for that MBMS session and proceed according to sub-clause 7.7.2.2. 

7.7.2 Establishment of MBMS bearer 
7.7.2.1 General 

The network may send an MBMS ASSIGNMENT message to the mobile station(s) in order to inform about the 
establishment of a radio bearer for an MBMS session in the cell or to notify the mobile station(s) that a radio bearer for 
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that MBMS session is not established in the cell. The decision of whether to establish a radio bearer for an MBMS 
session in a cell is a network dependent choice. 

If the network sends the MBMS ASSIGNMENT message subsequent to an MBMS Notification for the same MBMS 
session, the MBMS ASSIGNMENT message shall be sent on any PAGCH on the same PCCCH on which the network 
has sent the MBMS Notification or, if a packet control channel does not exist, the IMMEDIATE ASSIGNMENT 
message including the Multiple Blocks Packet Downlink Assignment construction shall be sent on any AGCH on the 
same CCCH on which the network has sent the MBMS Notification, followed by the MBMS ASSIGNMENT message 
sent on the PDCH specified by the Packet Channel Description IE in the IMMEDIATE ASSIGNMENT message (see 
3GPP TS 44.018). In case the network sends the MBMS ASSIGNMENT message in response to an MBMS SERVICE 
REQUEST message which is not sent as a response to an MBMS Notification, the MBMS ASSIGNMENT message 
shall be sent on any PAGCH on the same PCCCH on which the mobile station sent the PACKET CHANNEL 
REQUEST message with access type "Single block MBMS access" or, if a packet control channel does not exist, the 
IMMEDIATE ASSIGNMENT message including the Multiple Blocks Packet Downlink Assignment construction shall 
be sent on any AGCH on the same CCCH on which the mobile station sent the CHANNEL REQUEST message with 
access type "Single block MBMS access", followed by the MBMS ASSIGNMENT message sent on the PDCH 
specified by the Packet Channel Description IE in the IMMEDIATE ASSIGNMENT message (see 3GPP TS 44.018). 

7.7.2.2 On receipt of an MBMS ASSIGNMENT message 

On reception of the MBMS ASSIGNMENT message the mobile station shall stop timer T3214 if running and enters 
broadcast/multicast receive mode. 

If the MBMS ASSIGNMENT message indicates that a radio bearer is established for the MBMS session in the cell, and 
thus contains an MBMS bearer description, the mobile station shall set and start the session duration timer for this 
MBMS session with a value equal to the Estimated Session Duration and shall listen to downlink RLC blocks identified 
by the assigned MBMS Bearer Identity value on the defined PDCHs. The network may assign a radio resource on one 
or more PDCHs to be used for the radio bearer. The amount of radio resource to be reserved is a network dependent 
choice and shall not exceed the multislot capability of an MBMS capable mobile station (see 3GPP TS 45.002). The 
MBMS In-band Signalling Indicator information element included in the MBMS ASSIGNMENT message indicates 
whether or not the network shall send system information messages and (for mobile stations with an assigned MS_ID 
on that MBMS radio bearer) paging messages on the PACCH of the MBMS radio bearer. 

The MBMS bearer description may indicate an MBMS radio bearer starting time. If the mobile station receives the 
MBMS ASSIGNMENT message before the MBMS radio bearer starting time has expired, it shall wait until the point in 
time denoted by the MBMS radio bearer starting time, leave non-DRX mode, switch to the assigned PDCHs and start 
timer T3190. If the mobile station receives the MBMS ASSIGNMENT message after the MBMS radio bearer starting 
time has expired, it shall ignore the indicated MBMS radio bearer starting time, leave non-DRX mode, immediately 
switch to the assigned PDCHs and start timer T3190. If the mobile station receives an MBMS ASSIGNMENT message 
including an MBMS bearer description without an MBMS radio bearer starting time, it shall leave non-DRX mode, 
immediately switch to the assigned PDCHs and start timer T3190. The timer T3190 is restarted when receiving the first 
valid RLC data block including the assigned MBMS Bearer Identity. On expiry of timer T3190, the mobile station shall 
abort the procedure and repeat the MBMS packet access procedure for the MBMS session. 

If the mobile station receives more than one MBMS ASSIGNMENT message while it monitors the PCCCH or, if a 
packet control channel does not exist, the CCCH (see 3GPP TS 44.018), it shall act upon the most recently received 
message and shall ignore the previous message. 

If the MBMS ASSIGNMENT message indicates that no radio bearer is estabHshed for the MBMS session in the cell, 
the mobile station shall act according to the indication in the Reject cause. 

If the cause value indicates that further MBMS packet accesses are allowed for this MBMS session in the same 
cell, as long as the session duration timer for this MBMS session in the mobile station is still running, the mobile 
station may perform more access attempts for the current MBMS session in this cell or in any other cell where 
MBMS is supported by the network. 

If the cause value indicates that no further MBMS packet accesses are allowed for this MBMS session in the 
same cell, the mobile station shall not perform any further access attempts for the current MBMS session in this 
cell. As long as the session duration timer for this MBMS session in the mobile station is still running, the 
mobile station may perform access attempts for the MBMS session in any other cell to which the mobile station 
has performed cell reselection, if MBMS is supported by the network in that cell. 
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If the cause value indicates that no further MBMS packet accesses are allowed for this MBMS session in the 
same Routing Area, the mobile station shall not perform any further access attempts for the current MBMS 
session in this Routing Area. As long as the session duration timer for this MBMS session in the mobile station 
is still running, the mobile station may perform access attempts for the MBMS session in any other cell, in any 
other Routing Area, to which the mobile station has performed cell reselection, if MBMS is supported by the 
network in that cell. 

If the cause value indicates that no further MBMS packet accesses are allowed for this MBMS session in this 
PLMN, the mobile station shall not perform any further access attempts for the MBMS session. 

When the session duration timer for the MBMS session in the mobile station expires, the mobile station shall no longer 
perform access attempts for that MBMS session in any cell and shall indicate to the upper layers the end of the MBMS 
session. 

Independent on the Reject cause value received and on the expiry of the session duration timer for the MBMS session, 
the mobile station may always perform new MBMS packet accesses for the MBMS session if a new MBMS 
Notification addressing that MBMS session, and indicating that counting shall be performed, is received. 

In case the network sends the MBMS ASSIGNMENT message in response to an MBMS SERVICE REQUEST 
message which is not sent as a response to an MBMS Notification, and the MBMS ASSIGNMENT message contains 
the MBMS bearer description and an uplink feedback channel is used, then the network may include the TLLI of the 
mobile station, the MS_ID and the timing advance parameters in the MBMS ASSIGNMENT message. If no MS_ID 
identifier is available on the network side, the network notifies the mobile station of the lack of an MS_ID identifier, 
preventing the mobile station from repeating the MBMS packet access procedure in this cell. 

7.7.2.3 Abnormal cases 

If on the mobile station side timer T3214 expires indicating that no MBMS bearer will be established for the specific 
MBMS session in the cell or if the MBMS ASSIGNMENT message contains faulty parameters, the mobile station shall 
abort the MBMS packet access procedure. 

7.7.2.4 MBMS address assignment procedure 

In case an uplink feedback channel is associated to an established MBMS radio bearer, then the network may assign an 
MS_ID to a given mobile station receiving this MBMS radio bearer by sending an MBMS MS_ID ASSIGNMENT 
message including the MS_ID and the timing advance parameters assigned to the mobile station. The mobile station 
shall be addressed by its TLLI. This message shall not be sent before the point in time denoted by the MBMS radio 
bearer starting time, if present in the previous MBMS ASSIGNMENT message. 

On a given PDCH a mobile station having been allocated an MS_ID is identified with a TFI value including the MBMS 
Bearer Identity (in the most significant bit(s) of the TFI field) and the MS_ID (in the remaining least significant bit(s) of 
the TFI field). 

The mobile station shall respond with a PACKET CONTROL ACKNOWLEDGEMENT message in the uplink radio 
block specified if a valid RRBP field is received as part of the MBMS MS_ID ASSIGNMENT message. The network 
shall reset counter N3109 for that MS_ID on that MBMS radio bearer when transmitting for the first time the MBMS 
MS_ID ASSIGNMENT message including a polling request. If the network does not receive the PACKET CONTROL 
ACKNOWLEDGEMENT message in the specified radio block, it shall increment counter N3109 for that MS_ID and 
may retransmit the MBMS MS_ID ASSIGNMENT message. If N3109 = N3109_MAX, the network shall start timer 
T3199 for that MS_ID. While T3199 is running for a given MS_ID and MBMS radio bearer, the network shall not use 
that MS_ID in any RLC/MAC block belonging to that MBMS radio bearer. When timer T3199 expires, the network 
may reuse the corresponding MS_ID value for that MBMS radio bearer. 

An initial timing advance value may be provided in the MBMS ASSIGNMENT message or in the MBMS MS_ID 
ASSIGNMENT message in the Packet Timing Advance IE. Thereafter either the timing advance is updated with a 
PACKET POWER CONTROL/TIMING ADVANCE message or the continuous timing advance procedure is used. If 
timing advance timeslot number and index are provided in the MBMS ASSIGNMENT message or in the MBMS 
MS_ID ASSIGNMENT message, the mobile station shall use the continuous timing advance procedure, using its 
allocation on PTCCH (see 3GPP TS 45.010). Otherwise, the continuous timing advance procedure shall not be used. 
For the case where the timing advance value is not provided in the MBMS ASSIGNMENT message or in the MBMS 
MS_ID ASSIGNMENT message, the mobile station is not allowed to send normal bursts (e.g. (EGPRS) PACKET 
DOWNLINK ACK/NACK message) on the uplink until it has received a valid timing advance either through the 
continuous timing advance procedure or in a PACKET POWER CONTROL/TIMING ADVANCE message. 
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If the mobile station has been assigned an MS_ID in the MBMS ASSIGNMENT message before the point in time 
denoted by the MBMS radio bearer starting time, if present in the MBMS ASSIGNMENT message, the mobile station 
shall switch to the assigned PDCH(s) at the point in time denoted by the MBMS radio bearer starting time and start 
timers T3190 and T3290. If the MBMS radio bearer starting time has already expired or has not been included in the 
MBMS ASSIGNMENT message including the MS_ID, the mobile station shall switch to the assigned PDCH(s) within 
the reaction time defined in 3GPP TS 45.010 and start timers T3190 and T3290. If the mobile station is assigned an 
MS_ID in the MBMS MS_ID ASSIGNMENT message, the mobile station shall start timer T3290 within the reaction 
time defined in 3GPP TS 45.010. The mobile station shall restart timer T3190 whenever receiving an RLC/MAC block 
including the assigned MBMS Bearer Identity. In EGPRS TBF mode T3190 is also restarted when receiving an 
erroneous RLC data block for which the header is correctly received and which addresses the mobile station. The 
mobile station with an assigned MS_ID value shall restart timer T3290 whenever receiving an RLC/MAC block 
including the corresponding MBMS Bearer Identity and the MS_ID in the TFI field. 

7.7.3 MBMS Neighbour Cell Information Distribution 

The network shall indicate in GPRS Cell Options IE whether it supports the distribution of MBMS NEIGHBOURING 
CELL INFORMATION messages (see sub-clause 12.24). 

The network may send MBMS neighbour cell information to a mobile station during MBMS reception using the 
MBMS NEIGHBOURING CELL INFORMATION message on the PACCH. A mobile station, which receives this 
information, shall store the MBMS data channel information until refreshing or until the end of the MBMS session. 
During that period the information can be used for fast resumption of the MBMS reception in the neighbour cell (see 
sub-clause 8.1.6.2). 

The MS shall only combine information received in several instances of the MBMS NEIGHBOURING CELL 
INFORMATION messages that have the same value of the MBMS_PTM_CHANGE_MARK specified for a 
neighbouring cell. 

In case the target cell has PBCCH allocated, this information shall be included in the MBMS NEIGHBOURING CELL 
INFORMATION message, if the PBCCH parameters can be encoded via the means provided in the message. If present, 
the MS shall use this information in order to avoid BCCH decoding, if not otherwise necessary unless the PBCCH 
location is known via PSI3 and PSBbis messages, in the target cell. 



8 Medium Access Control (MAC) Procedures in Packet 

Transfer Mode 

8.0 General 

The MAC procedures defined in this sub-clause are applicable in packet transfer mode. They are applicable in dual 
transfer mode, if both the network and the mobile station support DTM. 

The procedures in this sub-clause (clause 8) shall not be used to change the frequency allocation of the mobile station in 
dual transfer mode. None of the PACKET DOWNLINK ASSIGNMENT, the MULTIPLE TBF DOWNLINK 
ASSIGNMENT, the PACKET UPLINK ASSIGNMENT, the MULTIPLE TBF UPLINK ASSIGNMENT, the 
PACKET TIMESLOT RECONFIGURE or the MULTIPLE TBF TIMESLOT RECONFIGURE messages shall include 
the Frequency Parameters IE when they are sent to a mobile station in dual transfer mode. 

NOTE: The network may use the DTM procedures on the main DCCH (the DTM ASSIGNMENT COMMAND 
message), if the radio resources for the RR connection and one or more TBF(s) need to be changed (see 
3GPPTS 44.018). 

8.1 Transfer of RLC data blocks 
8.1 .0 Medium access mode 

The transfer of RLC data blocks is governed by different principles on both uplink and downlink for each of the defined 
medium access modes: dynamic allocation, extended dynamic allocation, and exclusive allocation. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 88 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

The exclusive allocation is applicable only in dual transfer mode and MAC-DTM state and shall be used on a half -rate 
PDCH. 

8.1 .1 Uplink RLC data block transfer 

Prior to the initiation of RLC data block transfer on the uplink, the network assigns the following parameters to 
characterise the uplink TBF in the uplink assignment (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF 
UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE 
or PACKET CS RELEASE INDICATION) message: 

a Temporary Flow Identity (TFI). The mobile station shall set the TFI field of each uplink RLC data block to the 
TFI value assigned to the mobile station for that uplink TBF; 

a set of PDCHs to be used for the uplink transfer; 

a TBF Starting Time indication (optional in case of a dynamic or extended dynamic allocation). 

the PFI associated with each allocated TBF if the network and the mobile station both support multiple TBF 
procedures. 

All the RLC data blocks of an uplink TBF initiated by one phase access shall each contain a TLLI (in A/Gb mode) or a 
G-RNTI (in lu mode) field in the RLC data block header until the contention resolution is completed on the mobile 
station side (see sub-clause 7.1.2.3 and 3GPP TS 44.160). After the reaction time specified in 3GPP TS 45.010 no other 
RLC data blocks shall contain a TLLI field (in A/Gb mode) or a G-RNTI (in lu mode), except for those retransmitted 
RLC data blocks that originally contained a TLLI (in A/Gb mode) or a G-RNTI (in lu mode), which will be repeated 
including the same TLLI {in A/Gb mode) or G-RNTI (in lu mode) (see sub-clause 7.1.2.3a and 3GPP TS 44.160). The 
TLLI_BLOCK_CHANNEL_CODING parameter in the PACKET UPLINK ASSIGNMENT or in the MULTIPLE 
TBF UPLINK ASSIGNMENT message indicates whether a RLC data block containing a TLLI (in A/Gb mode) or a G- 
RNTI (in lu mode) field in the RLC data block header shall be encoded using CS-1, or correspondingly MCS-1 in 
EGPRS TBF mode, or using the commanded modulation and channel coding scheme (see 3GPP TS 45.003). In GPRS 
TBF mode, the mobile station shall send all other RLC data blocks using the commanded channel coding scheme. 

In EGPRS TBF mode, RLC data blocks that are transmitted for the first time shall be transmitted with the commanded 
MCS, except if the commanded mode is MCS-5-7, in which case the data block shall be transmitted with MCS-5, or if 
the commanded mode is MCS-6-9, in which case the data block shall be transmitted with MCS-6. In EGPRS TBF 
mode, a MS may choose an alternate MCS than the one commanded, for the initial transmission of the last RLC data 
blocks of the TBF under the following conditions: 

the alternate MCS is more robust than the commanded MCS; 

the alternate MCS has already been commanded by the network during the TBF or was available for selection by 
the MS during the TBF according to the MCS selection rules for retransmissions; and 

the TBF requires no more radio blocks for initial transmission of the RLC data blocks using the alternate MCS 
than would be required when using the commanded MCS. 

A RESEGMENT bit is included within each PACKET UPLINK ACK/NACK, PACKET UPLINK ASSIGNMENT, 
MULTIPLE TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION messages. For initial transmissions of new RLC blocks the 
channel coding commanded is applied. The RESEGMENT bit is used to set the ARQ mode to type I or type II 
(incremental redundancy) for uplink TBFs. For retransmissions, setting the RESEGMENT bit to '1' (type I ARQ) 
requires the mobile station to use an MCS within the same family as the initial transmission and the payload may be 
split (refer to table 8.1.1.1). For retransmissions, setting the RESEGMENT bit to '0' (type II ARQ) requires the mobile 
station to use an MCS within the same family as the initial transmission without splitting the payload even if the 
network has commanded it to use MCS-1, MCS-2 or MCS-3 for subsequent RLC blocks (refer to table 8.1.1.2), see 
note. In RLC unacknowledged mode, RESEGMENT bit shall be ignored and default value should be used. 

NOTE: This bit is particularly useful for networks with uplink IR capability since it allows combining on 
retransmissions. 
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Table 8.1.1.1 : Choice of MCS for retransmissions with re-segmentation 



Scheme 

used 

for 

initial 

transmi 
ssion 


Scheme to use for retransmissions after switching to a different MCS 




MCS-9 
Comm 
anded 


MCS-8 
Comm 
anded 


MCS-7 
Comm 
anded 


MCS- 

6-9 

Comm 

anded 


MCS-6 
Comm 
anded 


MCS- 

5-7 

Comm 

anded 


MCS-5 
Comm 
anded 


MCS-4 
Comm 
anded 


MCS-3 
Comm 
anded 


MCS-2 
Comm 
anded 


MCS-1 
Comm 
anded 


MCS-9 


MCS-9 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-8 


MCS-8 


MCS-8 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-3 
(pad) 


MCS-3 
(pad) 


MCS-3 
(pad) 


MCS-3 
(pad) 


MCS-3 
pad) 


MCS-3 
(pad) 


MCS-7 


MCS-7 


MCS-7 


MCS-7 


MCS-5 


MCS-5 


MCS-5 


MCS-5 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-6 


MCS-9 


MCS-6 


MCS-6 


MCS-9 


MCS-6 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-5 


MCS-7 


MCS-7 


MCS-7 


MCS-5 


MCS-5 


MCS-7 


MCS-5 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-1 


MCS-1 


MCS-1 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


NOTE: MCS to use for retransmissions when re-segmentation (RESEGMENT bit set to '1 ') is carried out (specified 
as a function of the scheme used for the initial transmission). 



Table 8.1.1.2: Choice of IVICS for retransmissions without re-segmentation 



Scheme 

used 

for 

Initial 

transmi 
ssion 


Scheme to use for retransmissions after switching to a different MCS 




MCS-9 
Comm 
anded 


MCS-8 
Comm 
anded 


MCS-7 
Comm 
anded 


MCS- 

6-9 

Comm 

anded 


MCS-6 
Comm 
anded 


MCS- 

5-7 

Comm 

anded 


MCS-5 
Comm 
anded 


MCS-4 
Comm 
anded 


MCS-3 
Comm 
anded 


MCS-2 
Comm 
anded 


MCS-1 
Comm 
anded 


MCS-9 


MCS-9 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-8 


MCS-8 


MCS-8 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-6 
(pad) 


MCS-7 


MCS-7 


MCS-7 


MCS-7 


MCS-5 


MCS-5 


MCS-5 


MCS-5 


MCS-5 


MCS-5 


MCS-5 


MCS-5 


MCS-6 


MCS-9 


MCS-6 


MCS-6 


MCS-9 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-6 


MCS-5 


MCS-7 


MCS-7 


MCS-7 


MCS-5 


MCS-5 


MCS-7 


MCS-5 


MCS-5 


MCS-5 


MCS-5 


MCS-5 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-4 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-3 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-2 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


MCS-1 


NOTE: MCS to use for retransmissions when re-segmentation is not (RESEGMENT bit set to '0') allowed (specified 
as a function of the scheme used for the initial transmission). 



If these rules require a transmission (either original transmission or retransmission) in a) MCS-7 or b) MCS-8 or 
MCS-9, but there is only one RLC block that can be transmitted in that MCS, the MS shall send that block in either 
MCS-5 for case a) or MCS-6 for case b). 

Upon receipt of a command from the network to change channel coding scheme, the mobile station shall react in 
accordance with the time specified in 3GPP TS 45.010. 

Upon receipt of any message containing an upUnk assignment (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE 
TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE, PACKET UPLINK ACK/NACK or PACKET CS RELEASE INDICATION message), the mobile 
station shall be ready to transmit in accordance with the requirements given in 3GPP TS 45.010. 

The mobile station shall transmit RLC/MAC blocks with the following priority: 
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- RLC/MAC control blocks containing a PACKET CS REQUEST message; 

- RLC/MAC control blocks containing a PACKET CELL CHANGE NOTIFICATION message; 
Other RLC/MAC control blocks, except Packet Uplink Dummy Control Blocks; 

- RLC data blocks; 

RLC/MAC control blocks containing Packet Uplink Dummy Control Blocks. 

NOTE: Within the respective reaction times specified in 3GPP TS 45.010 at uplink assignment, change of coding 
scheme and completion of the contention resolution at one phase access, the mobile station may send 
RLC/MAC control blocks containing Packet Uplink Dummy Control Blocks, if there is no other block 
ready to be transmitted. 

In A/Gb mode, during the TBF, if the countdown procedure has not started or the TBF is operated in the extended 
uplink TBF mode (see sub-clause 9.3.1b) and multiple TBF procedures are not supported (i.e. the mobile station or the 
network does not support multiple TBF procedures) the mobile station shall ask for new or different radio resources, by 
sending a PACKET RESOURCE REQUEST message (sub-clauses 8.1.1.1.2), in the following cases; 

When the mobile station has indicated Page Response, Cell update or Mobility Management procedure as access 
type in the PACKET CHANNEL REQUEST message and it has data to send. 

When the mobile station has data to send with a lower priority than indicated in the PACKET CHANNEL 
REQUEST or EGPRS PACKET CHANNEL REQUEST message. 

When the mobile station has indicated 'Signalling' as access type in the EGPRS PACKET CHANNEL 
REQUEST message and it has data to send. 

In A/Gb mode or lu mode, a mobile station that supports multiple TBF procedures shall send a PACKET RESOURCE 
REQUEST message to a network supporting multiple TBF procedures (see sub-clause 8.1.1.1.2), if it has data to send 
for one or more PFCs (A/Gb mode) or RBs (lu mode) for which no uplink TBFs are established. 

8.1 .1 .1 Dynamic allocation uplink RLC data block transfer 

This sub-clause specifies mobile station behaviour for dynamic allocation uplink RLC data block transfer while in 
packet transfer mode, MAC-Shared State, dual transfer mode or MAC-DTM state. 

When the mobile station receives an uplink assignment (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE 
TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) that does not contain a TBF starting time, the 
mobile station shall begin monitoring the downlink PDCHs corresponding to (i.e. with the same timeslot number as) the 
assigned uplink PDCHs for the assigned USE value for each assigned uplink PDCH within the reaction time defined in 
3GPP TS 45.010. If a TBF starting time information element is present and no uplink TBFs are in progress, but one or 
more downlink TBFs are in progress, the mobile station shall wait until the starting time before beginning to monitor 
the USFs and using the newly assigned uplink TBF parameters. While waiting for the starting time, the mobile station 
shall monitor the assigned downlink PDCHs. If a TBF starting time information element is present and one or more 
uplink TBFs are already in progress, the mobile station shall continue to use the assigned parameters of the ongoing 
uplink TBFs until the TDMA frame number indicated by the TBF starting time occurs, at which time the mobile station 
shall immediately begin to use the newly assigned uplink TBF parameters. The mobile station shall continue to use the 
newly assigned parameters of each uplink TBF until the TBF is either released or reconfigured. If while waiting for the 
frame number indicated by the TBF starting time the mobile station receives another uplink assignment, the mobile 
station shall act upon the most recently received uplink assignment and shall ignore the previous uplink assignment. 

If a mobile station has requested multiple uplink TBFs in a PACKET RESOURCE REQUEST message the network 
may allocate resources for these TBFs by sending one or more uplink assignment messages in response (see sub-clause 
8.1.1.1.2). The mobile station shall act upon each successive uplink assignment message as it is received. 

Whenever the mobile station detects an assigned USE value on a downlink PDCH corresponding to an assigned uplink 
PDCH, the mobile station shall transmit either a single RLC/MAC block or a sequence of four RLC/MAC blocks on the 
same PDCH for that TBF except if that TBF is running in extended uplink TBF mode, in which case the mobile station 
may transmit RLC/MAC block(s) for other TBFs assigned on the same PDCH (see sub-clause 9.3. lb. 2). The time 
relation between an uplink block, which the mobile station shall use for transmission, and the occurrence of the USE 
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value is defined in 3GPP TS 45.002. The number of RLC/MAC blocks to transmit is controlled by the 
USF_GRANULARITY parameter characterising the uplink TBF. 

When the mobile station transmits an RLC/MAC block to the network, it shall start timer T3180 for the uplink TBF on 
which the block was sent. When the mobile station detects an assigned USF value on a downlink PDCH corresponding 
to an assigned uplink PDCH for that TBF, the mobile station shall restart timer T3180. If any given timer T3180 
expires, the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 (A/Gb mode) or 
3GPP TS 44.160 (lu mode). 

Whenever the network receives a valid RLC/MAC block for any given TBF, it shall reset counter N3101 for that TBF. 
The network shall increment counter N3101 for each radio block, allocated to that TBF, for which no data is received. If 
N3101 = N3101max, the network shall stop the scheduHng of RLC/MAC blocks for that TBF and start timer T3169. 
When T3169 expires, the network may reuse the USF and TFI allocated to that TBF. If PS Handover is ongoing it is 
optional for the network to increment N3 lOI . 

8.1.1.1.1 PACCH operation 

The mobile station shall attempt to decode every downlink RLC/MAC block on all the downlink PDCHs corresponding 
to (i.e. with the same timeslot number as) the assigned uplink PDCHs. Whenever the mobile station receives an 
RLC/MAC block containing an RLC/MAC control block, the mobile station shall attempt to interpret the message 
contained therein. If the message addresses the mobile station, the mobile station shall act on the message. 

Whenever the mobile station detects an assigned USF value on any downlink PDCH corresponding to an assigned 
uplink PDCH, the mobile station may transmit a PACCH block on the same PDCH in the next block period (see 
3GPP TS 45.002). The mobile station shall not transmit an RLC data block in any uplink radio block allocated via the 
polling mechanism (see sub-clause 10.4.4). 

8.1.1.1.2 Resource Reallocation for Uplink 

The mobile station and the network are not allowed to change the RLC mode nor TBF mode of an already established 
TBF during resource reallocation. Change of RLC mode or TBF mode shall be achieved through release of on-going 
TBF and establishment of a new TBF with the newly requested RLC mode or TBF mode. If a new mode is assigned by 
the network for an already established TBF, the MS shall ignore the new assigned mode and shall maintain the TBF in 
the old mode. 

During an uplink packet transfer, upper layers may request to transfer another upper layer PDU with a different PFI, a 
different Radio Priority, a different peak throughput class or a different RLC mode than the one which is in transfer. An 
upper layer PDU containing signalling shall be treated as having the highest Radio Priority, and the acknowledged RLC 
mode shall be requested. 

If the mobile station or the network does not support multiple TBF procedures the following procedures apply: 

If the mobile station has not started the countdown procedure or the TBF is operated in the extended uplink TBF 
mode (see sub-clause 9.3.1b) and the new upper layer PDU has the same RLC mode as the current uplink TBF 
and either a higher radio priority or the same radio priority but a higher peak throughput class, the mobile station 
shall immediately request a resource reallocation for uplink according to the new Radio Priority and peak 
throughput class of the new upper layer PDU by sending a PACKET RESOURCE REQUEST message on the 
PACCH and starting timer T3168 for the uplink TBF requested in the PACKET RESOURCE REQUEST 
message. Then the mobile station shall complete the transmission of the current upper layer PDU. 

If the new upper layer PDU has the same RLC mode as the current uplink TBF and either a lower Radio Priority 
or the same radio priority but a lower peak throughput class, the mobile station shall first complete the sending 
of the upper layer PDU in transfer. When the sending of upper layer PDUs at the higher Radio Priority or the 
same radio priority but higher peak throughput class stops, without waiting for the acknowledgement from the 
network if in RLC acknowledged mode, the mobile station shall then perform the request of a resource 
reallocation for uplink for any remaining upper layer PDU(s) by sending a PACKET RESOURCE REQUEST 
message on the PACCH and start timer T3168 for the uplink TBF requested in the PACKET RESOURCE 
REQUEST message. However if the upper layer PDUs at the higher Radio Priority does not completely fill the 
RLC data block the MS shall fill this RLC data block with new upper layer PDUs and then either transmit first 
the PACKET RESOURCE REQUEST message and subsequently the RLC data block or vice versa. 
If the new upper layer PDU does not have the same RLC mode as the current uplink TBF but has a higher radio 
priority, the mobile station shall complete the transmission of the current upper layer PDU using the countdown 
procedure including acknowledgement from the network, if in RLC acknowledged mode. If the TBF is operated 
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in non-extended uplink TBF mode, the mobile station shall then release the TBF and establish a new uplink TBF 
for transmission of the new upper layer PDU. If the TBF is operated in extended uplink TBF mode (see sub- 
clause 9.3.1b), the mobile station shall use the procedure in sub-clause 8.1.1.6 for changing the RLC mode. 
When the sending of upper layer PDUs with a higher radio priority is completed using the countdown procedure, 
including acknowledgement from the network if in RLC acknowledged mode, the mobile station shall try to 
establish an uplink TBF for the transmission of any remaining upper layer PDU(s). 

If the mobile station has not started the countdown procedure or the TBF is operated in the extended uplink TBF 
mode (see sub-clause 9.3.1b) and the new upper layer PDU does not have the same PFI but the same radio 
priority and the same peak throughput class as the current uplink TBF, the mobile station shall immediately 
request a resource reallocation for uplink with the new PFI by sending a PACKET RESOURCE REQUEST 
message on the PACCH and starting timer T3168 for the uplink TBF requested in the PACKET RESOURCE 
REQUEST message. Then the mobile station shall complete the transmission of the current upper layer PDU. 

If both the mobile station and the network support multiple TBF procedures the following procedures apply: 

The mobile station shall initiate a request for one or more new uplink TBFs when it has upper layer PDUs 
associated with one or more PFIs for which there are no ongoing uplink TBFs. In this case it sends a PACKET 
RESOURCE REQUEST message on the PACCH and starts an instance of timer T3168 for each uphnk TBF 
requested. 

All ongoing uplink TBFs shall continue to operate using their currently allocated resources. 

On receipt of the PACKET RESOURCE REQUEST message the network shall respond by sending either an uplink 
assignment message (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK ASSIGNMENT, PACKET 
TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE) or a PACKET ACCESS REJECT 
message to the mobile station on the downlink PACCH. 

If the mobile station or the network does not support multiple TBF procedures, then after the transmission of the 
PACKET RESOURCE REQUEST message with the reason for changing PFI, the priority or peak throughput class of 
an assigned uplink TBF the mobile station shall continue to use the currently assigned uplink TBF assuming that the 
requested priority or peak throughput class is already assigned to that TBF. 

If both the mobile station and the network support multiple TBF procedures, then after transmission of a PACKET 
RESOURCE REQUEST message the mobile station shall maintain its ongoing uplink TBFs using their currently 
allocated TBF parameters. 

On receipt of an uphnk assignment message (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK 
ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE message) 
sent in response to a PACKET RESOURCE REQUEST message the mobile station shall stop timer T3168 for each 
uplink TBF assigned in the assignment message and switch to the assigned PDCHs. A mobile station that supports 
multiple TBF procedures shall act on the uplink assignment message as defined in sub-clause 8.1.2.5. 

If the mobile station or the network does not support multiple TBF procedures, the mobile station is then not allowed to 
send new PACKET RESOURCE REQUEST messages until either a new packet transfer request is received from the 
upper layers or when sending of upper layer PDU(s) at a lower Radio Priority has to be continued. 

If the mobile station or the network does not support multiple TBF procedures, upon expiry of timer T3 168 the mobile 
station shall retransmit the PACKET RESOURCE REQUEST message unless the PACKET RESOURCE REQUEST 
message has already been transmitted four times in which case the mobile station shall perform an abnormal release 
with access retry (see sub-clause 8.7.2). 

If both the mobile station and the network support multiple TBF procedures, then upon expiry of all instances of timer 
T3168 the mobile station shall retransmit the PACKET RESOURCE REQUEST message to request resources for those 
uplink TBFs that did not receive an uplink assignment unless the PACKET RESOURCE REQUEST message has 
already been transmitted four times without receiving any uplink assignment in response. In this case the mobile station 
shall perform an abnormal release with access retry (see sub-clause 8.7.2). 

If no assignment message (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK ASSIGNMENT, 
PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE message) addressing any 
requested uplink TBF is received before the mobile station has completed its currently assigned TBFs the mobile station 
shall stop all instances of timer T3168. 
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The network may at any time during uplink packet transfer initiate a change of resources by sending on the downhnk 
PACCH monitored by the MS, an unsoHcited upHnk assignment message (e.g. PACKET UPLINK ASSIGNMENT, 
MULTIPLE TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) to the mobile station. During the reallocation, 
TFI is allowed to be changed. A mobile station that supports multiple TBF procedures shall act on the uplink 
assignment message as defined in sub-clause 8.1.2.5. 

On receipt of a PACKET ACCESS REJECT message, the mobile station shall stop timer T3168, if running, for the 
TBFs rejected in the PACKET ACCESS REJECT message, abort the uplink TBFs and indicate a packet access failure 
to the upper layer associated with each rejected TBF. If no more uplink or downlink TBFs exist, the mobile station in 
packet transfer mode shall return to packet idle mode; the mobile station in dual transfer mode shall return to dedicated 
mode. The DRX mode procedures shall be applied, as specified in sub-clause 5.5.1.5. 

If the PACKET ACCESS REJECT message contains a WAITJNDICATION field in a Reject structure addressed to 
the mobile station, the mobile station shall: 

If the mobile station or the network does not support multiple TBF procedures, start timer T3 172 and if the 
mobile station has additional RLC data blocks to transmit, it shall initiate a new uplink TBF establishment, but 
the mobile station is not allowed to make a new attempt for an uplink TBF establishment in the same cell until 
timer T3172 expires, it may, however, attempt an uplink TBF establishment in an other cell after successful cell 
reselection. The mobile station may attempt to enter the dedicated mode in the same cell before timer T3172 has 
expired. During the time T3172 is running, the mobile station shall ignore all received PACKET PAGING 
REQUEST messages except paging request to trigger RR connection establishment. 

If both the mobile station and the network support multiple TBF procedures the mobile station shall start one 
instance of timer T3172 for each uplink TBF that was rejected. All TBFs in progress that are not rejected shall be 
maintained. The mobile station is not allowed to attempt re-establishment of a rejected uplink TBF in the same 
cell until its associated instance of timer T3 172 expires. It may, however, attempt re-establishment of a rejected 
uplink TBF in another cell after successful cell reselection. The mobile station may attempt to enter the 
dedicated mode in the same cell before all instances of timer T3172 have expired. During the time one or more 
instances of T3172 are running, the mobile station shall ignore all received PACKET PAGING REQUEST 
messages except paging request to trigger RR connection establishment. 

The value of the WAJT_INDICATION field (i.e. timer T3172) relates to the cell from which it was received. 

8.1.1.1.2.1 Abnormal cases 

The following abnormal cases apply: 

If the mobile station receives an uplink assignment message (e.g. PACKET UPLINK ASSIGNMENT, 
MULTIPLE TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF 
TIMESLOT RECONFIGURE or PACKET CS RELEASE INDICATION message) and detects an invalid 
Frequency Parameters information element in the message, the mobile station shall perform an abnormal release 
with system information (see sub-clause 8.7.3), performing a partial acquisition of system information messages 
containing frequency information. 

If the mobile station receives an uplink assignment message (e.g. PACKET UPLINK ASSIGNMENT, 
MULTIPLE TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF 
TIMESLOT RECONFIGURE or PACKET CS RELEASE INDICATION message) specifying frequencies that 
are not all in one frequency band then the mobile station shall perform an abnormal release with access retry (see 
sub-clause 8.7.2). 

- If the information in the PACKET UPLINK ASSIGNMENT or the MULTIPLE TBF UPLINK ASSIGNMENT 
message does not properly specify an uplink PDCH or violates the mobile station's multislot capabilities, the 
mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2). 

- If the information in the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message does not properly specify an uplink and 
downlink PDCH or violates the mobile station's multislot capabilities, the mobile station shall perform an 
abnormal release with access retry (see sub-clause 8.7.2). 

- If the mobile station receives a PACKET UPLINK ASSIGNMENT or a MULTIPLE TBF UPLINK 
ASSIGNMENT message containing a Frequency Parameters information element specifying a frequency that is 
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in a frequency band not supported by the mobile station then the mobile station shall perform an abnormal 
release with access retry (see sub-clause 8.7.2). 

- If a mobile station in dual transfer mode receives a PACKET UPLINK ASSIGNMENT, MULTIPLE TBF 
UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT 
RECONFIGURE message including the Frequency Parameters information element, the mobile station shall 
perform an abnormal release with access retry (see sub-clause 8.7.2). 

- If a failure in the uplink assignment message (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF 
UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) is due to any other reason, the mobile 
station shall perform an abnormal release with access retry (see sub-clause 8.7.2). 

If both the mobile station and the network support multiple TBF procedures and if any given uplink assignment 
message provides an uplink TBF allocation for a PFI not indicated in the PACKET RESOURCE REQUEST 
message and not associated with any ongoing uplink TBF, the mobile station shall abort the procedure and 
perform an abnormal release with access retry (see sub-clause 8.7.2). 

NOTE: An uplink assignment message (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK 
ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) received by a multi-band mobile 
station shall not be considered invalid if it indicates new frequencies that are all in a different frequency 
band to that of the PDCH(s) on which the assignment was received. The assignment may however be 
rendered invalid for some other reason. 

8.1 .1 .1 .3 Establishment of Downlink TBF 

During uplink transfer, the network may initiate the establishment of one or more downlink TBFs by sending a 
downlink assignment message (e.g. PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF 
DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE PACKET CS RELEASE INDICATION) to the mobile station on the PACCH. If a PACKET 
TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or a MULTIPLE TBF 
DOWNLINK ASSIGNMENT message is sent, then the message shall contain the DOWNLINK_TFI_ ASSIGNMENT 
field for each downlink TBF being established. If multiple TBF procedures are supported by the mobile station and the 
network, the network shall indicate the PFI associated with each TBF it allocates or reallocates in the downlink 
assignment message. The network shall not attempt to establish multiple downlink TBFs for a mobile station with only 
one uplink TBF unless the mobile station's radio access capabilities are known.The multislot restrictions of the mobile 
station shall be observed. 

A mobile station that supports multiple TBF procedures shall act on the downlink assignment message as follows: 

- Upon reception of a PACKET DOWNLINK ASSIGNMENT message the mobile station shall release all 
ongoing downlink TBFs not addressed by this message and shall act on the message. All ongoing uplink TBFs 
shall be maintained. 

- Upon reception of a PACKET TIMESLOT RECONFIGURE message the mobile station shall release all 
ongoing uplink and downlink TBFs not addressed by this message and shall act on the message. 

- Upon reception of a MULTIPLE TBF DOWNLINK ASSIGNMENT message the mobile station shall maintain 
all ongoing TBFs not addressed by this message using its currently allocated TBF parameters and shall act on the 
message. 

- Upon reception of a MULTIPLE TBF TIMESLOT RECONFIGURE message the mobile station shall release all 
ongoing uplink and downlink TBFs not addressed by this message and shall act on the message. 

Upon reception of a PACKET CS RELEASE INDICATION message the mobile station shall release all ongoing 
uplink and/or downlink TBFs not addressed by this message and shall act on the message. 

A mobile allocation or reference frequency list, received as part of a downlink assignment, replaces the previous 
parameters and shall be used until a new assignment is received or the mobile station has released all TBFs. 

On receipt of a downlink assignment message, and after the TBF starting time, if present, the mobile station shall switch 
to the assigned PDCHs, and start timer T3190 for each of the TBFs assigned. The operation of the downlink TBFs 
follow the procedures in sub-clause 8.1.2 and 3GPP TS 44.160 with the following additions: 
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the mobile station shall prioritise transmission of RLC/MAC control blocks associated with a downlink TBF 
over RLC/MAC control blocks associated with an uplink TBF; 

if a timer or counter expiry causes an uplink TBF to be aborted in the mobile station, the mobile station shall 
perform an abnormal release with access retry as specified in sub-clause 8.7.2 (A/Gb mode) or 3GPP TS 44.160 
(lu mode); 

If one uplink and one downlink TBF are already established, then the network may send a PACKET TIMESLOT 
RECONFIGURE or a PACKET CS RELEASE INDICATION message without 

DOWNLINK_TFI_ASSIGNMENT. The mobile station shall interpret this as a reassignment of the timeslot 
allocations of the concurrent uplink and downlink TBFs and the downlink TFI is not changed. 

8.1.1.1.3.1 Abnormal cases 

If a failure occurs on the mobile station side before the new TBF(s) has been successfully established, the newly 
reserved resources are released. The subsequent behaviour of the mobile station depends on the type of failure and 
previous actions: 

- If the information in the PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT 
RECONFIGURE message does not properly specify an uplink and downlink PDCH or violates the mobile 
station's multislot capabilities, the mobile station shall perform an abnormal release with access retry (see sub- 
clause 8.7.2 and 3GPP TS 44.160). 

- If one uplink and one downlink TBF are not already established and the PACKET TIMESLOT RECONFIGURE 
message does not include a DOWNLINK_TFI_ASSIGNMENT field, then the mobile station shall perform an 
abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

If a mobile station in dual transfer mode or MAC-DTM state receives a downlink assignment message (e.g. 
PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET 
TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or PACKET CS RELEASE 
INDICATION message) including the Frequency Parameters information element, the mobile station shall 
perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160. 

- If a failure in the PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE 

message is due to any other reason, the mobile station shall abort the procedure and perform an abnormal release 
with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

If both the mobile station and the network support multiple TBF procedures and if any given downlink 
assignment message provides an uplink TBF allocation for a PFI not associated with any ongoing uplink TBF, 
the mobile station shall abort the procedure and perform an abnormal release with access retry (see sub-clause 
8.7.2 and 3GPPTS 44.160). 

- If a failure in the PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT or 
PACKET CS RELEASE INDICATION message is due to any other reason, the mobile station shall abort the 
procedure and continue the normal operation of the ongoing uplink TBFs and ongoing downlink TBFs. 

8.1 .1 .2 Extended Dynamic Allocation uplink RLC data block transfer 

The Extended Dynamic Allocation medium access method extends the Dynamic Allocation medium access method to 
allow higher uplink throughput. 

This sub-clause defines the extensions to the Dynamic Allocation medium access method. All procedures defined in 
sub-clause 8.1.1.1 apply, except where this sub-clause defines a new procedure. In cases where this sub-clause conflicts 
with sub-clause 8.1.1.1, this sub-clause takes precedence. 

8.1 .1 .2.1 Uplink PDCH Allocation 

The PACKET UPLINK ASSIGNMENT and MULTIPLE TBF UPLINK ASSIGNMENT messages assign to the mobile 
station a subset of 1 to N uplink PDCHs, where N depends on the mobile station multislot class. 

The mobile station shall monitor the downlink PDCHs corresponding to (i.e. with the same timeslot number as) its 
assigned uplink PDCHs starting with the lowest numbered PDCH, then the next lowest numbered PDCH, etc., up to the 
one corresponding to the highest numbered assigned uplink PDCH. When in dual transfer mode, the network shall not 
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assign uplink PDCHs whose corresponding downlink PDCH cannot be monitored by the mobile station because of the 
presence of the uplink dedicated channel. As an exception, in the case of dual transfer mode, if the mobile station 
indicates support of DTM high multislot class capability, the network may also assign uplink PDCHs whose 
corresponding downlink PDCH cannot be monitored by the mobile station. In this case, the mobile station shall monitor 
only those downlink PDCHs that are feasible when taking into account the position of the uplink dedicated channel and 
the switching requirements of its multislot class (see 3GPP TS 45.002). 

Whenever the mobile station detects an assigned USF value on a monitored PDCH, the mobile station shall transmit 
either a single RLC/MAC block or a sequence of four RLC/MAC blocks on the corresponding uplink PDCH (i.e. with 
the same timeslot number as the downlink PDCH on which the USF was detected) and all higher numbered assigned 
uplink PDCHs. The time relation between an uplink block, which the mobile station shall use for transmission, and the 
occurrence of the USF value is defined in 3GPP TS 45.002. The number of RLC/MAC blocks to transmit on each 
PDCH is controlled by the USF_GRANULARITY parameter characterising the uplink TBF. The mobile station shall 
ignore the USF on those higher numbered PDCHs during the block period where the assigned USF value is detected. In 
addition, if USF_GRANULARITY is set to four blocks allocation, it may ignore the USF on all other PDCHs during 
the first three block periods in which the mobile station has been granted permission to transmit. As specified in 3GPP 
TS 45.002, the USF corresponding to the last three blocks of a four blocks allocation shall be set to an unused value for 
each PDCH on which the mobile station has been granted permission to transmit. 

The mobile station shall, during a block period in which it has been granted permission to transmit, monitor for the 
assigned USF the downlink PDCHs corresponding to its assigned uplink PDCHs starting with the lowest numbered 
assigned PDCH up to the highest numbered PDCH which the mobile is able to monitor, taking into account the PDCHs 
allocated for transmission in the block period and the switching requirements of the mobile station multislot class (see 
3GPP TS 45.002). 

If the network wishes to reduce the number of PDCHs allocated to a mobile station per block period, the network may 
do so, provided that this is compatible with the mobile station's ability to monitor for the assigned USF the downlink 
PDCH corresponding to the lowest numbered uplink PDCH in the new allocation. Otherwise, the network shall not 
allocate any resources to that mobile station for one block period following the block period with the higher number of 
PDCHs allocated. 

During the block period where an uplink radio block is allocated on a PDCH via the polling mechanism (see sub-clause 
10.4.4), the mobile station shall monitor for the assigned USF on the downlink PDCHs corresponding to its assigned 
uplink PDCHs starting with the lowest numbered assigned PDCH up to the highest numbered PDCH which is feasible 
when taking into account the PDCH's allocated for transmission in the block period and the switching requirements of 
the mobile station multislot class (see 3GPP TS 45.002). 

8.1 .1 .2.2 PACCH operation 

The mobile station shall attempt to decode every downlink RLC/MAC block on the downlink PDCH corresponding to 
(i.e. with the same timeslot number as) the lowest numbered timeslot in the PDCH assignment. Whenever the mobile 
station receives an RLC/MAC block containing an RLC/MAC control block, the mobile station shall attempt to 
interpret the message contained therein. If the message addresses the mobile station, the mobile station shall act on the 

message. 

The network shall transmit all PACCH messages on the PDCH carried on the downlink timeslot corresponding to the 
lowest numbered timeslot in the assignment. Additionally for the concurrent TBF case, the network may transmit 
PACCH messages on any of the common timeslots assigned to the downlink and uplink PDCHassignment. 

Whenever the mobile station detects an assigned USF value on any monitored PDCH, the mobile station may transmit a 
PACCH block on the same PDCH in the next block period. The mobile station shall not transmit an RLC data block in 
any uplink radio block allocated via the polling mechanism (see sub-clause 10.4.4). 

8.1 .1 .2.3 Neighbour cell power measurements 

The mobile station shall perform neighbour cell measurements during any unused PDCH or group of unused PDCHs 
where the MS's Measurement Capabilities indicate that the mobile station is capable of making a neighbour cell 
measurement. 

The network shall ensure that there are sufficient gaps as to allow the necessary number of measurements based upon 
the MS's Measurement Capabilities. 
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8.1 .1 .2.4 Shifted USF operation 

In some instances (see 3GPP TS 45.002), Shifted USF operation shall apply. 

When Shifted USF operation is used, the USF for the first assigned uplink PDCH shall be sent on the downlink PDCH 
corresponding to (i.e. with the same timeslot number as) the second assigned uplink PDCH. The MS shall monitor this 
downlink PDCH for the USF corresponding to both the first assigned uplink PDCH and the second assigned uplink 
PDCH. If the USF corresponding to the first assigned uplink PDCH is detected then the mobile station shall transmit on 
the first assigned uplink PDCH and all higher numbered assigned uplink PDCHs. Otherwise, operation shall be as 
described in sub-clause 8.1.1.2.1. 

The USF value corresponding to the first assigned uplink PDCH shall be different from the USF value corresponding to 
the second assigned uplink PDCH. 

When Shifted USF operation is used, PACCH operation shall be as described in sub-clause 8.1.1.2.2 except that the 
network shall transmit all PACCH messages on the PDCH carried on the downlink timeslot corresponding to the second 
lowest numbered timeslot in the uplink assignment, and the mobile station shall attempt to decode every downlink 
RLC/MAC block on that downlink PDCH. 

If a PACKET PDCH RELEASE message releases the second uplink PDCH in the current timeslot configuration of a 
mobile station using Shifted USF operation then the first uplink timeslot shall also be considered released. If any 
PDCHs remain in the new timeslot configuration then normal USF operation shall continue starting on the lowest 
available timeslot. 

8.1.1.3 (void) 

8.1 .1 .3a Exclusive allocation RLC data block transfer 

8.1.1.3a.1 General 

This sub-clause specifies mobile station behaviour for exclusive allocation of radio resources for uplink RLC data block 
transfer. The exclusive allocation is applicable only in dual transfer mode (for half -rate PDCHs only) and MAC-DTM 
state (for half-rate PDCHs only). The conditions for using exclusive allocation are specified in sub-clause 8.1.0. 

When the mobile station receives an uplink assignment (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE 
TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT 
RECONFIGURE) that does not contain a TBF starting time, the mobile station shall switch to the assigned PDCHs and 
be ready to transmit within the reaction time defined in 3GPP TS 45.010. If a TBF starting time is present, the mobile 
station shall wait until the starting time before it switches to the assigned PDCHs and starts to transmit. If a TBF 
starting time is present and an uplink TBF or one or more downlink TBFs are already in progress, the mobile station 
shall continue to use the previously assigned resources for the uplink TBF until the TBF starting time occurs. If the 
mobile station receives another uplink assignment, while waiting for the TBF starting time, the mobile station shall act 
upon the most recently received uplink assignment and shall ignore the previous one. 

When mobile station has received the uplink assignment and been granted the right to transmit using exclusive 
allocation, the mobile station shall start timer T3184 and transmit an RLC/MAC block in every uplink radio block on 
the PDCHs assigned for the TBF. The timer T3184 shall be restarted every time the mobile station receives a 
PACKET UPLINK ACK/NACK message. 

The timer T3184 shall be stopped at the release of the TBF. The timer T3184 shall also be stopped if the resources for 
the TBF are reallocated, such that the conditions for exclusive allocation are no longer fulfilled and the TBF continues 
using dynamic or extended dynamic allocation (see sub-clause 8.1.0). 

A mobile station supporting multiple TBF procedures and operating in DTM mode with exclusive allocation may only 
establish a single uplink TBF. However, one or more downlink TBFs may still be established when exclusive allocation 
is used for the uplink TBF. In this case the network may allocate the radio resources for the uplink TBF by sending the 
mobile station one of the following messages: 

- A PACKET UPLINK ASSIGNMENT message if there is no more than one concurrent downlink TBF. 

- A MULTIPLE TBF UPLINK ASSIGNMENT message if there are multiple concurrent downlink TBFs. 
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- A PACKET TIMESLOT RECONFIGURE message if there is one concurrent downlink TBF that is also being 
reallocated. 

- A MULTIPLE TIMESLOT RECONFIGURE message if there are multiple concurrent downlink TBFs and at 
least one of them is being reallocated or there are multiple concurrent downlink TBFs and resources for at least 
one new downlink TBF are being allocated. 

8.1.1.3a.2 Radio link failure 

If timer T3184 expires (see sub-clause 8.LL3a.l), the mobile station shall regard that as a radio link failure and perform 
an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

The network shall increment counter N3101 for each radio block allocated to the TBF for which no RLC/MAC block is 
received. Whenever the network receives an RLC/MAC block from the mobile station, it shall reset counter N3101 for 
that TBF. If N3101 reaches the value N3 101 max, the network shall stop sending PACKET UPLINK ACK/NACK 
messages to the mobile station for that TBF and shall start timer T3169 for the TBF. If an RLC/MAC block is received 
from the TBF when timer T3169 is running, the network shall stop timer T3169 and resume sending 
PACKET UPLINK ACK/NACK messages to the TBF. When T3169 expires, the network may consider the TBF as 
released and reuse the TFI value. If PS Handover is ongoing, it is optional for the network to increment N3101. 

8.1.1.3a.3 (void) 

8.1.1 .3a.4 PACCH operation 

The mobile station shall attempt to decode every downlink RLC/MAC block on the PDCH with the lowest timeslot 
number assigned for the uplink TBF. Whenever the mobile station receives an RLC/MAC block containing an 
RLC/MAC control block, the mobile station shall attempt to interpret the message contained therein. If the message is a 
distribution message or a non-distribution message that addresses the mobile station, the mobile station shall act on the 

message. 

During the transmission on the uplink TBF, the mobile station may use any uplink RLC/MAC block, assigned for the 
uplink TBF, for the transmission of an RLC/MAC control block (PACCH). The mobile station shall not transmit an 
RLC data block in any uplink RLC/MAC block allocated to the mobile station via the polling mechanism (see sub- 
clause 10.4.4). 

8.1 .1 .3a.5 Resource Reallocation for Uplink 

8.1.1 .3a.5.1 General 

The reallocation of radio resources may take place during an uplink TBF, due to a change of service demand from the 
mobile station, or due to reasons determined by the network. This procedure shall not be used to change neither the 
RLC mode nor the TBF mode of the uplink TBF. A change of RLC mode or TBF mode shall be achieved through the 
release of the uplink TBF and establishment of a new TBF. 

8.1 .1 .3a. 5. 2 Change of service demand 

During an uplink packet transfer, upper layers may request the transfer an upper layer PDU with a different PFI, a 
different radio priority, a different peak throughput class or a different RLC mode than the one, which is in transfer. In 
case of an upper layer PDU containing signalling information, it shall be transferred with the highest radio priority and 
requesting acknowledged RLC mode. 

If upper layers request the transfer of another upper layer PDU with a different PFI, a different Radio Priority, a 
different peak throughput class or a different RLC mode than the one which is in transfer, then the procedures as 
described in packet transfer mode (see sub-clause 8.1.1.1.2) shall be applied by the mobile station. 

If the mobile station, at the change of service demand, has started the countdown procedure (see sub-clause 9.3.1) in 
order to release the uplink TBF, the mobile station shall perform the release of the uplink TBF as normal. The mobile 
station may then establish a new uplink TBF, according to the new service demand. 

If the countdown procedure has not been started or the TBF is operated in the extended uplink TBF mode (see sub- 
clause 9.3.1b) and the new upper layer PDU shall be transferred with the same RLC mode as the current uplink TBF, 
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the mobile station shall indicate a change of service demand to the network by sending a PACKET RESOURCE 
REQUEST message on PACCH. 

When the PACKET RESOURCE REQUEST message is sent, the mobile station shall start timer T3168. 

If the new upper layer PDU shall be transmitted with a different RLC mode than the current uplink TBF, the mobile 
station may complete the transmission of the preceding upper layer PDUs and shall then release the TBF and establish a 
new uplink TBF for transmission of the new upper layer PDU. If the TBF is operated in extended TBF mode (see sub- 
clause 9.3.1b), the mobile station shall use the procedure in sub-clause 8.1.1.6 for changing the RLC mode. 

After the transmission of the PACKET RESOURCE REQUEST message, the mobile station shall continue to use the 
currently assigned uplink TBF, assuming that the network grants the requested service demand. 

On receipt of the PACKET RESOURCE REQUEST message the network shall respond by either the reallocation of 
radio resources for an uplink TBF (sub-clause 8.1.1.3a.5.3) or the rejection of service demand (sub-clause 8. 1.1. 3a. 5. 4). 

The mobile station shall stop timer T3168 at the receipt of a PACKET UPLINK ASSIGNMENT, a MULTIPLE TBF 
UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or a MULTIPLE TBF TIMESLOT 
RECONFIGURE message, or when the mobile station has completed its currently assigned TBFs. If timer T3168 
expires, the mobile station shall retransmit the PACKET RESOURCE REQUEST message and again start timer T3168. 

8.1 .1 .3a. 5. 3 Reallocation of radio resources for an uplink TBF 

The network may reallocate the radio resources for an uplink TBF by sending the mobile station a 
PACKET UPLINK ASSIGNMENT or a PACKET CS RELEASE INDICATION message if there is no more than one 
concurrent downlink TBF or a MULTIPLE TBF UPLINK ASSIGNMENT or a PACKET CS RELEASE 
INDICATION message if there are multiple concurrent downlink TBFs. If there is a concurrent downlink TBF and the 
radio resources for the downlink TBF are also affected, the network shall use a PACKET TIMESLOT RECONFIGURE 
or a PACKET CS RELEASE INDICATION message for the reallocation. If there are multiple concurrent downlink 
TBFs and the radio resources for at least one downlink TBF are also affected, the network shall use a MULTIPLE TBF 
TIMESLOT RECONFIGURE or a PACKET CS RELEASE INDICATION message for the reallocation. 

On receipt of the PACKET UPLINK ASSIGNMENT , the MULTIPLE TBF UPLINK ASSIGNMENT, the PACKET 
TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or the PACKET CS RELEASE 
INDICATION message, the mobile station shall treat the message as an uplink assignment, as defined in sub-clause 
8.1.1.1.2. On receipt of the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE 
or the PACKET CS RELEASE INDICATION message, the mobile station shall, in addition, treat the message as a 
downlink assignment, as defined in sub-clause 8.1.2.1. 

8.1 .1 .3a. 5. 4 Rejection of new service demand 

On the receipt of a PACKET RESOURCE REQUEST message from the mobile station indicating a change of service 
demand, the network may reject the service demand by sending a PACKET ACCESS REJECT message to the mobile 
station. 

On receipt of the PACKET ACCESS REJECT message, the mobile station shall stop timer T3168 if running, abort the 
uplink TBF and indicate a packet access failure to upper layers. If no downlink TBF exists, the mobile station in dual 
transfer mode shall return to dedicated mode. The DRX mode procedures shall be applied, as specified in sub- 
clause 5.5.1.5. 

The PACKET ACCESS REJECT message may contain a wait indication (i.e. the WAITJNDICATION field) in the 
Reject structure addressed to the mobile station. In that case, the mobile station shall start timer T3172 with the 
indicated value. The mobile station shall not attempt to establish a new uplink TBF in the same cell while timer T3172 
is running. If a successful cell reselection is performed, the mobile station shall stop timer T3172 and may establish an 
uplink TBF in the new cell. 

While timer T3172 is running, the mobile station shall ignore any PACKET PAGING REQUEST message that may be 
received, except paging requests to trigger RR connection establishment and paging request including MBMS 
notification. 

8.1.1 .3a. 5. 5 Abnormal cases 

The following abnormal cases apply: 
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If timer T3168 expires and the PACKET RESOURCE REQUEST message has already been transmitted four 
times, the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 
3GPPTS 44.160). 

- If the mobile station receives an uplink assignment (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF 
UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) including the Frequency Parameters 
information element, the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 
and 3GPPTS 44.160). 

- If a failure in the uplink assignment (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK 
ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or 
PACKET CS RELEASE INDICATION message) is due to any other reason, the mobile station shall perform an 
abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

8.1 .1 .3a.6 Establishment of Downlink TBF 

8.1.1.3a.6.1 General 

During an uplink TBF using exclusive allocation, the network may initiate the establishment of one or more downlink 
TBFs by sending a downlink assignment message (e.g. PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF 
DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT 
RECONFIGURE message) to the mobile station on the PACCH. If multiple TBF procedures are not supported the 
PACKET TIMESLOT RECONFIGURE message shall be used if the timeslot allocation for the on-going uplink TBF 
needs to be changed. If the mobile station and network support multiple TBF procedures the PACKET 
DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET TIMESLOT 
RECONFIGURE and MULTIPLE TBF TIMESLOT RECONFIGURE messages shall be used as described in sub- 
clause 8.1.1.1.3. 

On receipt of the downlink assignment message (e.g. PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF 
DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) the mobile station shall switch to the assigned 
PDCHs. If the assignment message includes a TBF starting time, the mobile station shall first wait until the indicated 
starting time and then switch to the assigned PDCHs. If the assigning message does not include a TBF starting time, or 
the TBF starting time has already passed when the assigning message is received, the mobile station shall switch to the 
assigned PDCHs within the reaction time specified in 3GPP TS 45.010. 

When the mobile station switches to the assigned PDCHs, it starts timer T3190 for each downlink TBF assigned. The 
operation of the downlink TBFs then follows the procedures defined in sub-clause 8.1.2 and 3GPP TS 44.160, with the 
following additions: 

The mobile station shall prioritise transmission of RLC/MAC control blocks associated with a downlink TBF 
over RLC/MAC control blocks associated with the uplink TBF. 

If a timer or counter expiry causes the uplink TBF to be aborted in the mobile station, the mobile station shall 
perform an abnormal release according to the procedure defined for the uplink TBF, which may cause also the 
downlink TBF to be aborted. 

If one uplink and one downlink TBF are established, the network may send a PACKET TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message without the 

UPLINK_TFI_ASSIGNMENT field. The mobile station shall interpret this as a reassignment of the concurrent 
uplink and downlink TBFs. The TFI of the uplink TBF is not changed. 

8.1.1 .3a. 6. 2 Abnormal cases 

If a failure occurs on the mobile station side before the downlink TBF has been successfully established, the newly 
reserved resources are released. The subsequent behaviour of the mobile station depends on the type of failure and 
previous actions: 

- If the information in the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message does not properly specify an uplink and 
downlink PDCH or violates the multislot capabilities of the mobile station, the mobile station shall perform an 
abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 
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- If a downlink TBFs is not already established and the PACKET TIMESLOT RECONFIGURE or PACKET CS 
RELEASE INDICATION message does not include a DOWNLINK_TFI_ASSIGNMENT field, then the mobile 
station shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If a mobile station in dual transfer mode receives a PACKET DOWNLINK ASSIGNMENT MULTIPLE TBF 
DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT 
RECONFIGURE message including the Frequency Parameters information element, the mobile station shall 
perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If a failure in the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or 
PACKET CS RELEASE INDICATION message is due to any other reason, the mobile station shall abort the 
procedure and perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If a failure in the PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT 
message is due to any other reason, the mobile station shall abort the procedure and continue the normal 
operation of the ongoing uplink and downlink TBFs. 

8.1 .1 .4 Network initiated release of uplink TBF 

The network may initiate release of an uplink TBF by transmitting a PACKET TBF RELEASE message to the mobile 
station on the PACCH. A cause value indicates the reason for release. 

If the cause value is "Normal release" the mobile station shall continue to the next upper layer PDU boundary, starting 
the count down procedure (see sub-clause 9.3.1) at whatever value of CV is appropriate to count down to zero at the 
upper layer PDU boundary, and then release the uplink TBF according to the procedures in sub-clause 9.3.2.3 or 
9.3.3.3. If multiple TBF procedures are not supported and the mobile station has more upper layer PDU(s) to send, the 
mobile station may initiate the establishment of a new uplink TBF as defined in sub-clause 7.1, 8.1.1 and 
3GPP TS 44.160. If the mobile station and network support multiple TBF procedures the mobile station may initiate the 
establishment of one or more new uplink TBFs as defined in sub-clause 8.1.1 and 8.1.1.1.2. 

If the cause value is "Abnormal Release", the mobile station shall abort the uplink TBF and perform an abnormal 
release with access retry (see sub-clause 8.7.2 and 3GPP TS 44. 160). If a valid RRBP field is received as part of the 
PACKET TBF RELEASE message, the mobile station shall transmit a PACKET CONTROL 
ACKNOWLEDGEMENT message in the upUnk radio block specified. 

8.1.1.5 Abnormal cases 

The following abnormal cases apply: 

- if the mobile station receives a PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK 
ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE, 
PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT or PACKET CS 
RELEASE INDICATION message with an invalid Frequency Parameters information element, the mobile 
station shall perform an abnormal release with system information (see sub-clause 8.7.3), performing a partial 
acquisition of system information messages containing frequency information. 

- if the mobile station receives a PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK 
ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE, 
PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT or PACKET CS 
RELEASE INDICATION message specifying frequencies that are not all in one band then the mobile shall 
perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If a mobile station in dual transfer mode receives a PACKET UPLINK ASSIGNMENT, MULTIPLE TBF 
UPLINK ASSIGNMENT, PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK 
ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or a MULTIPLE TBF TIMESLOT RECONFIGURE 
message including the Frequency Parameters information element, the mobile station shall perform an abnormal 
release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

if the mobile station receives a PACKET UPLINK ACK/NACK message with missing mandatory fields, the MS 
shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

if the mobile station is operating in the non-extended uplink TBF mode (see sub-clause 9.3. lb) and the mobile 
station has not started, or has started but not completed the countdown procedure for a given TBF and it receives 
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a PACKET UPLINK ACK/NACK message with the Final Ack Indicator set for that TBF, it shall perform an 
abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

NOTE: A PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK ASSIGNMENT, PACKET 
TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE, 

PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT or PACKET 
CS RELEASE INDICATION message sent to a multi-band mobile station shall not be considered invalid 
if it indicates new frequencies that are all in a different frequency band to that of the ARFCN of the 
serving cell. 

8.1 .1 .6 Change of RLC mode in extended uplink TBF mode 

8.1.1.6.1 General 

This procedure applies to a mobile station having an uplink TBF in extended uplink TBF mode. The procedure shall be 
used to release the ongoing uplink TBF and to setup a new TBF in another RLC mode. 

8.1 .1 .6.2 Change of RLC mode 

The mobile station shall send a PACKET RESOURCE REQUEST message on PACCH indicating the new RLC mode 
and start timer T3168. 

If timer T3I68 expires, the mobile station shall retransmit the PACKET RESOURCE REQUEST message and restart 
timer T3 168. 

On receipt of a PACKET RESOURCE REQUEST message, indicating a change of RLC mode, the network shall 
release the uplink TBF at a point determined by the network, using the procedure defined in sub-clause 9.5. 

On receipt of PACKET UPLINK ACK/NACK with Final Ack Indicator set to '1' the mobile station shall stop timer 
T3168 and after sending the PACKET CONTROL ACK perform the change of RLC mode by establishing a new TBF. 

8.1.1.6.3 Abnormal cases 

The following abnormal cases apply: 

If timer T3 168 expires and the PACKET RESOURCE REQUEST message has already been transmitted four 
times, the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2). 

8.1 .2 Downlink RLC data block transfer 

Prior to the initiation of RLC data block transfer on the downlink, the network assigns the following parameters in a 
downlink assignment (e.g. PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT, 
PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or PACKET CS RELEASE 
INDICATION) message: 

a Temporary Flow Identity (TFI). The TFI applies to all radio blocks transferred in regards to the downlink 
Temporary Block Flow (TBF); 

a set of PDCHs to be used for the downlink transfer; 

optionally, a TBF starting time indication, 

a PFI associated with each allocated TBF if the network and the mobile station both support multiple TBF 
procedures. 

For each TBF, the network shall prioritise RLC/MAC control blocks, not containing a 

PACKET DOWNLINK DUMMY CONTROL BLOCK message, to be transmitted ahead of RLC data blocks for that 
TBF. If the network has no other RLC/MAC block to transmit, but wishes to transmit on the downlink, the network 
shall transmit an RLC/MAC control block containing a PACKET DOWNLINK DUMMY CONTROL BLOCK 

message. 
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8.1 .2.1 Downlink RLC data block transfer 

A network may send an unsolicited downlink assignment message to a mobile station. A mobile station that supports 
multiple TBF procedures shall act on the uplink assignment message as defined in sub-clause 8.1.1.1.3. 

Upon reception of a downlink assignment that does not contain a TBF starting time the mobile station shall start timer 
T3190 for each downlink TBF assigned in the downlink assignment message and within the reaction time defined in 
3GPP TS 45.010, it shall attempt to decode every downlink block on its assigned PDCHs. If the downlink assignment 
message (e.g. PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET 
TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or PACKET CS RELEASE 
INDICATION message) contains a TBF starting time information element and there is no downlink TBF in progress, 
but one or more uplink TBFs are in progress, the mobile station shall remain on the assigned PDCHs until the TDMA 
frame number indicated by the TBF starting time, at which time the mobile station shall start timer T3190 for each 
downlink TBF assigned in the downlink assignment message and immediately begin decoding the assigned downlink 
PDCH(s). If the downhnk assignment message (e.g. PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF 
DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) contains a TBF starting time and there are one 
or more downlink TBFs already in progress, the mobile station shall continue to use the parameters of the downlink 
TBFs in progress until the TDMA frame number indicated in the TBF starting time occurs, at which time the mobile 
station shall immediately begin to use the new assigned downlink TBF parameters. The mobile station shall continue to 
use the newly assigned parameters of each downlink TBF until the TBF is either released or reconfigured. If while 
waiting for the frame number indicated by the TBF starting time the mobile station receives another downlink 
assignment for the TBF, the mobile station shall act upon the most recently received downlink assignment and shall 
ignore the previous downlink assignment. Procedures on receipt of a downlink assignment message (e.g. 
PACKET DOWNLINK ASSIGNMENT or MULTIPLE TBF DOWNLINK ASSIGNMENT message) while no TBF is 
in progress are specified in sub-clause 7.2.1.1 and 3GPP TS 44.160. 

If the mobile station receives a valid RLC data block addressed to one of its TBFs, the mobile station shall restart timer 
T3190 for that TBF. In EGPRS TBF mode T3190 is also restarted when receiving an erroneous RLC data block for 
which the header is correctly received and which addresses the mobile station. 

If any given timer T3190 expires, the mobile station shall release that downlink TBF. If there are one or more uplink 
TBFs in progress, the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 
3GPP TS 44.160). If any given timer T3190 expires and there are no other ongoing uplink TBFs in progress, the mobile 
station shall perform an abnormal release without retry (see sub-clause 8.7.1). 

Upon receipt of a PACKET TBF RELEASE message referring to a downlink TBF, the mobile station shall follow the 
procedure in sub-clause 8.1.2.8. 

8.1.2.1.1 Abnormal cases 

If a failure occurs on the mobile station side before one or more new TBFs have been successfully established, the 
newly reserved resources are released. The subsequent behaviour of the mobile station depends on the type of failure 
and previous actions: 

- If a mobile station receives a downlink assignment message (e.g. PACKET DOWNLINK ASSIGNMENT, 
MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF 
TIMESLOT RECONFIGURE or PACKET CS RELEASE INDICATION message) and detects an invalid 
Frequency Parameters information element in the message, it shall perform an abnormal release with system 
information (see sub-clause 8.7.3), performing a partial acquisition of system information messages containing 
frequency information. 

- If a mobile station in dual transfer mode receives a PACKET DOWNLINK ASSIGNMENT, a MULTIPLE TBF 
DOWNLINK ASSIGNMENT, a PACKET TIMESLOT RECONFIGURE or a MULTIPLE TBF TIMESLOT 
RECONFIGURE message including the Frequency Parameters information element, the mobile station shall 
perform an abnormal release with access retry if there is at least one ongoing uplink TBF (see sub-clause 8.7.2 
and 3GPP TS 44.160), otherwise it shall perform an abnormal release without retry (see sub-clause 8.7.1 and 
3GPPTS 44.160). 

- If the information in the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message does not properly specify an uplink and 
downlink PDCH or violates the mobile station's multislot capabilities, the mobile station shall perform an 
abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 
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- If the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or PACKET 
CS RELEASE INDICATION message does not include a DOWNLINK_TFI_ASSIGNMENT field, then the 
mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If a failure in the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or 
PACKET CS RELEASE INDICATION message is due to any other reason, the mobile station shall abort the 
procedure and perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

If the information available in the mobile station, after the reception of a 

PACKET DOWNLINK ASSIGNMENT or MULTIPLE TBF DOWNLINK ASSIGNMENT message does not 

satisfactorily define a PDCH, the mobile station shall ignore the 

PACKET DOWNLINK ASSIGNMENT/MULTIPLE TBF DOWNLINK ASSIGNMENT message. 

- If the mobile station receives a PACKET DOWNLINK ASSIGNMENT or MULTIPLE TBF 
DOWNLINK ASSIGNMENT message containing different frequency parameters than are currently in effect for 
the uplink TBF, the mobile station shall ignore the PACKET DOWNLINK ASSIGNMENT/ MULTIPLE TBF 
DOWNLINK ASSIGNMENT message and continue normal operation of the uplink TBF. 

- If a failure in the PACKET DOWNLINK ASSIGNMENT or MULTIPLE TBF DOWNLINK ASSIGNMENT 
message is due to any other reason, the mobile station shall abort the establishment of the downlink TBFs 
indicated in the downlink assignment message. If one or more ongoing uplink or downlink TBFs exist, the 
mobile station shall continue the normal operation of all the ongoing uplink TBFs. If no ongoing uplink or 
downlink TBFs exist, the mobile station shall perform an abnormal release without retry (see sub-clause 8.7.1). 

If both the mobile station and the network support multiple TBF procedures and if any given downlink 
assignment message provides an uplink TBF allocation for a PFI not associated with any ongoing uplink TBF, 
the mobile station shall abort the procedure and perform an abnormal release with access retry (see sub-clause 
8.7.2 and 3GPPTS 44.160). 

8.1 .2.2 Polling for Packet Downlink Ack/Nack 

Whenever the mobile station receives an RLC data block addressed to one of its TBFs and with a valid RRBP field in 
the RLC data block header (i.e. is polled), the mobile station shall transmit one of the following messages in the uplink 
radio block specified by the RRBP field whatever the BSN value of the received RLC data block, according to the 
subsequent decreasing order of priority: 

1) (EGPRS) PACKET DOWNLINK ACK/NACK message containing a Final Ack Indicator, 

2) PACKET CS REQUEST, if such a message is waiting to be transmitted, 

3) PACKET CELL CHANGE NOTIFICATION, if such a message is waiting to be transmitted, 

4) (EGPRS) PACKET DOWNLINK ACK/NACK message containing a Channel Request Description IE, 

5) any other RLC/MAC control message, if such a message is waiting to be transmitted, other than a (EGPRS) 
PACKET DOWNLINK ACK/NACK, 

6) (EGPRS) PACKET DOWNLINK ACK/NACK message not containing a Final Ack Indicator or a Channel 
Request Description IE. 

However, the mobile station shall transmit an RLC/MAC control message other than a (EGPRS) 
PACKET DOWNLINK ACK/NACK message at most every second time it is polled for the TBF. 

The mobile station shall not send a PACKET CONTROL ACKNOWLEDGEMENT message unless otherwise 
specified. 

In EGPRS TBF mode the mobile station shall react on a poll inside an erroneously received RLC data block for which 
the header is correctly received and which addresses the mobile station. 

Whenever the network receives a valid RLC/MAC control message from a TBF, it shall reset counter N3105 for that 
TBF. The network shall increment counter N3105 for each radio block, allocated to that TBF with the RRBP field, for 
which no RLC/MAC control message is received. If N3105 = N3105max, the network shall release the downlink TBF 
internally and start timer T3195 for that TBF. When T3195 expires, the network may reuse the TFI. 
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The PACKET DOWNLINK ACK/NACK message contains a Channel Quality Report (see 3GPP TS 45.008). The 
optional 1_LEVEL measurement results shall be included in at least every other PACKET DOWNLINK ACK/NACK 

message. 

The EGPRS PACKET DOWNLINK ACK/NACK message may contain an EGPRS Channel Quahty Report (see 
3GPP TS 45.008). 

In the case of simultaneous uplink and downlink TBFs, the transmission of the polling response takes precedence over 
the transmission of allocated uplink radio blocks. 

A mobile station of multislot class 1 to 12 or multislot class 30 to 45 need not respond to the poll if it is not compliant 
with the multislot class of the mobile station (see 3GPP TS 45.002). 

A mobile station of multislot class 13 to 18 shall always respond to the poll. 

A mobile station of multislot class 19 to 29 may omit the allocated downlink PDCHs with timeslot numbers greater than 
n+1, while transmitting the polling response on timeslot number n. If the remaining configuration is not compliant with 
the multislot class of the mobile station (see 3GPP TS 45.002), the mobile station need not respond to the poll. 

NOTE: The mobile station is required to make neighbour cell measurements while transmitting the polling 
response (see 3GPP TS 45.008). 

In case of simultaneous uplink and downlink TBFs and extended dynamic allocation (see sub-clause 8.1.1.2), the 
network may apply polling in downlink RLC data blocks only when sent on a PDCH common for both reception and 
transmission (see 3GPP TS 45.002). A mobile station operating with extended dynamic allocation need to respond to 
polling in downlink RLC data blocks only when received on a PDCH common for both reception and transmission. 

8.1.2.3 (void) 

8.1 .2.4 Resource Reassignment for Downlink 

The network initiates resource reassignment by sending a downlink assignment message (e.g. 
PACKET DOWNLINK ASSIGNMENT, MULTIPLE THE DOWNLINK ASSIGNMENT, PACKET TIMESLOT 
RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or PACKET CS RELEASE INDICATION 
message) on the downlink PACCH. These messages indicate a change in resources in the same TBF. The Control Ack 
bit in the message shall be set to '0'. If multiple TBF procedures are supported by the mobile station and the network, 
the network shall indicate the PFI associated with each TBF it allocates or reallocates in the downlink assignment 
message. During the reassignment of any given TBF its associated TFI is allowed to be changed. Mobile shall use the 
TFI indicated in the PACKET DOWNLINK ASSIGNMENT/ MULTIPLE TBF DOWNLINK ASSIGNMENT when 
using the resource indicated in the message. 

The network is not allowed to change the RLC mode nor TBF mode of an already established TBF during resource 
reallocation. Change of RLC mode or TBF mode shall be achieved through release of on-going TBF and establishment 
of a new TBF with the newly requested RLC mode or TBF mode using the procedures described in sub-clause 9.3.2.5 
or sub-clause 9.3.3.5. 

On receipt of a downhnk assignment message (e.g. PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF 
DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) and after the TBF starting time, if present, the 
mobile station shall switch to the assigned PDCHs. Upon switching to the new PDCHs the mobile station shall restart 
timer T3190 for each newly assigned downlink TBF. A mobile station that supports multiple TBF procedures shall act 
on the uplink assignment message as defined in sub-clause 8.1.1.1.3. 

When the mobile station receives an RLC/MAC block addressed to (one of) its downlink TBF(s) on any of the new 
assigned resources it shall restart timer T3190 for that TBF. If any given timer T3190 expires, and if one or more uplink 
TBF is in progress, the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 
3GPP TS 44.160). If any given timer T3190 expires and there are no uplink TBFs in progress, the mobile station shall 
perform an abnormal release without retry (see sub-clause 8.7.1). 

8.1.2.4.1 Abnormal cases 

These abnormal cases apply during establishment of downlink TBF after downlink TBF release (see sub-clause 9.3.2.6). 
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If a failure occurs on the mobile station side before the new TBF has been successfully established, the newly reserved 
resources are released. The subsequent behaviour of the mobile station depends on the type of failure and previous 
actions: 

- If a mobile station receives a downlink assignment message (e.g. PACKET DOWNLINK ASSIGNMENT, 
MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF 
TIMESLOT RECONFIGURE or PACKET CS RELEASE INDICATION message) and detects an invalid 
Frequency Parameters information element in the message, the mobile station shall perform an abnormal release 
with system information (see sub-clause 8.7.3), performing a partial acquisition of system information messages 
containing frequency information. 

- If a mobile station in dual transfer mode or MAC-DTM state receives PACKET DOWNLINK ASSIGNMENT, 
a MULTIPLE TBF DOWNLINK ASSIGNMENT, a PACKET TIMESLOT RECONFIGURE or a MULTIPLE 
TBF TIMESLOT RECONFIGURE message including the Frequency Parameters information element, the 
mobile station shall perform an abnormal release with access retry if there is at least one ongoing uplink TBF 
(see sub-clause 8.7.2 and 3GPP TS 44.160), otherwise it shall perform an abnormal release without retry (see 
sub-clause 8.7.1 and 3GPP TS 44.160). 

- If the information in the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message does not properly specify an uplink and 
downlink PDCH or violates the mobile station's multislot capabilities, the mobile station shall perform an 
abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If a failure in the PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT RECONFIGURE or 
PACKET CS RELEASE INDICATION message is due to any other reason, the mobile station shall abort the 
procedure and perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

If the information available in the mobile station, after the reception of a PACKET DOWNLINK 
ASSIGNMENT or MULTIPLE TBF DOWNLINK ASSIGNMENT message does not satisfactorily define a 
PDCH, the mobile station shall ignore the PACKET DOWNLINK ASSIGNMENT / MULTIPLE TBF 
DOWNLINK ASSIGNMENT message and maintain its ongoing TBFs. 

- If the mobile station receives a PACKET DOWNLINK AS SIGNMENT or MULTIPLE TBF 
DOWNLINK ASSIGNMENT message containing different frequency parameters than are currently in effect for 
its ongoingTBFs, the mobile station shall ignore the PACKET DOWNLINK ASSIGNMENT message and 
continue normal operation of its ongoingTBFs. 

- If a failure in the PACKET DOWNLINK ASSIGNMENT or MULTIPLE TBF DOWNLINK ASSIGNMENT 
message is due to any other reason, the mobile station shall abort the establishment of the downlink TBFs 
indicated in the downlink assignment message. If one or more ongoing uplink or downlink TBFs exist, the 
mobile station shall continue the normal operation of all ongoing uplink TBFs. If no ongoing uplink or downlink 
TBFs exist, the mobile station shall perform an abnormal release without retry (see sub-clause 8.7.1). 

If both the mobile station and the network support multiple TBF procedures and if any given downlink 
assignment message provides an uplink TBF allocation for a PFI not associated with any ongoing uplink TBF, 
the mobile station shall abort the procedure and perform an abnormal release with access retry (see sub-clause 
8.7.2 and 3GPPTS 44.160). 

8.1.2.5 Establishment of uplink TBF 

The mobile station may request establishment of one or more uplink TBFs when there are one or more ongoing 
downlink TBFs by including a Channel Request Description or the Extended Channel Request Description information 
element in the (EGPRS) PACKET DOWNLINK ACK/NACK message. Initiation is triggered by a request from upper 
layers to transfer an upper layer PDU. The request from upper layers specifies a Radio Priority to be associated with the 
packet transfer. Upon such a request, 

if access to the network is allowed, according to the latest values for authorised special access classes that the 
mobile station has received (see sub-clause 7.1.1 and 3GPP TS 44.160), the mobile station shall initiate the 
packet access procedure. 

otherwise, the RR (in A/Gb mode) or the MAC (in lu mode) sublayer in the mobile station shall reject the 
request. 
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When multiple TBF procedures are not supported, the mobile station initiates the packet access procedure by sending 
the Channel Request Description information element in the (EGPRS) PACKET DOWNLINK ACK/NACK message 
on the PACCH and starting timer T3168. 

When the mobile station and the network support multiple TBF procedures the mobile station may request one or more 
uplink TBFs by including the Extended Channel Request Description information element in the (EGPRS) 
PACKET DOWNLINK ACK/NACK message and starting one instance of timer T3168 for each uplink TBF it requests. 
Each requested uplink TBF is associated with a different PEL A mobile station shall continue to use its ongoing 
downlink TBFs unless re-allocated or released as a result of the uplink assignment message(s) sent in response by the 
network. 

On receipt of an (Extended) Channel Request Description information element in the 

(EGPRS)PACKET DOWNLINK ACK/NACK message, the network may assign radio resources to the mobile station 
on one or more PDCHs by transmitting an uplink assignment message (e.g. PACKET UPLINK ASSIGNMENT, 
MULTIPLE TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT 
RECONFIGURE message) on the PACCH, or may reject one or more of the requests by sending a PACKET ACCESS 
REJECT message on the PACCH. If the PACKET TIMESLOT RECONFIGURE message is sent, then the message 
shall contain the UPLINK_TFI_ASSIGNMENT field. 

If multiple TBF procedures are supported by the mobile station and the network, the network shall indicate the PFI 
associated with each TBF it allocates or reallocates in the uplink assignment message. 

A mobile allocation or reference frequency list, when received in the Frequency Parameters IE, as part of an uplink 
assignment, replaces the previous parameters and shall be used until a new assignment is received or the mobile station 
has released all TBFs. 

On receipt of an uplink assignment message (e.g. PACKET UPLINK ASSIGNMENT, MULTIPLE TBF 

UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE 

message) the mobile station shall proceed as follows: 

On reception of an uplink assignment message the mobile station shall stop the instance of timer T3 168 
associated with the TBF receiving a resource allocation. 

The mobile station shall, after expiry of the TBF starting time, if present, act upon the uplink assignment 
received for that TBF. 

The mobile station shall then switch to the assigned uplink PDCHs and begin to send RLC data blocks on the 
assigned PDCH(s). Neither the TLLI (in A/Gb mode) nor the G-RNTI (in lu mode) shall be included in any of 
the uplink RLC data blocks in that case. 

A mobile station that supports multiple TBF procedures shall act on the uplink assignment message as follows: 

Upon reception of a PACKET UPLINK ASSIGNMENT message the mobile station shall release all ongoing 
uplink TBFs not addressed by this message and shall act on the message. If multiple uplink TBFs were requested 
then the mobile station shall consider those not addressed by this message as rejected and shall stop the 
corresponding T3168 timer instances. All ongoing downlink TBFs shall be maintained. 

- Upon reception of a PACKET TIMESLOT RECONFIGURE message the mobile station shall release all 
ongoing uplink and downlink TBFs not addressed by this message and shall act on the message. If multiple 
uplink TBFs were requested then the mobile station shall consider those not addressed by this message as 
rejected and shall stop the corresponding T3168 timer instances. 

- Upon reception of a MULTIPLE TBF UPLINK ASSIGNMENT message the mobile station shall maintain all 
ongoing TBFs not addressed by this message using its currently allocated TBF parameters and shall act on the 
message. If a requested uplink TBF is not addressed by this message and the associated timer T3168 is still 
running the mobile station shall wait for another instance of this message. 

- Upon reception of a MULTIPLE TBF TIMESLOT RECONFIGURE message the mobile station shall release all 
ongoing uplink and downlink TBFs not addressed by this message and shall act on the message. If multiple 
uplink TBFs were requested then the mobile station shall consider those not addressed by this message as 
rejected and shall stop the corresponding T3168 timer instances. 

On receipt of a PACKET ACCESS REJECT message that contains a Reject structure addressed to the mobile station, 
the mobile station shall stop the instance of timer T3 168 associated with each uplink TBF being rejected and indicate a 
packet access failure to the corresponding upper layers. 
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If the PACKET ACCESS REJECT message contains a WAITJNDICATION field in a Reject stracture addressed to 
the mobile station, it shall proceed as follows: 

If multiple TBF procedures are not supported the mobile station shall start timer T3172 with the indicated value 
(Wait Indication). The mobile station is not allowed to make a new attempt for uplink TBF establishment in the 
same cell until timer T3172 expires, but it may attempt uplink TBF establishment in an other cell after successful 
cell reselection. 

If both the mobile station and the network support multiple TBF procedures the mobile station shall start one 
instance of timer T3172 for each uplink TBF that was rejected. All ongoing TBFs shall be maintained. The 
mobile station is not allowed to attempt re-establishment of a rejected uplink TBF in the same cell until its 
associated instance of timer T3 172 expires. It may, however, attempt re-establishment of a rejected uplink TBF 
in another cell after successful cell reselection. The mobile station may attempt to enter the dedicated mode in 
the same cell before all instances of timer T3172 have expired. During the time one or more instances of T3172 
are running, the mobile station shall ignore all received PACKET PAGING REQUEST messages except paging 
request to trigger RR connection establishment and paging request including MBMS notification. 

If all instances of timer T3168 have expired, the mobile station shall retransmit the (Extended) Channel Request 
Description information element in the next (EGPRS) PACKET DOWNLINK ACK/NACK message unless the 
(Extended) Channel Request Description has already been transmitted four times in which case the mobile station shall 
perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). If all the ongoing downlink 
TBFs are released, including expiry of timer T3 192, before expiry of all instances of timer T3 168 and no uplink TBFs 
are either ongoing or have received an uplink assignment with a TBF starting time, the mobile station shall stop all 
remaining instances of timer T3168 and perform an abnormal release with access retry (see sub-clause 8.7.2 and 
3GPPTS 44.160). 

8.1.2.5.1 Abnormal cases 

If a failure occurs on the mobile station side before a new TBF has been successfully established, the newly reserved 
resources are released. The subsequent behaviour of the mobile station depends on the type of failure and previous 
actions. 

- If the information in the PACKET UPLINK ASSIGNMENT or MULTIPLE TBF UPLINK ASSIGNMENT 
message violates the mobile station's multislot capabilities, the mobile station shall perform an abnormal release 
with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If the mobile station receives a PACKET UPLINK AS SIGNMENT or a MULTIPLE TBF 

UPLINK ASSIGNMENT message containing different frequency parameters than are currently in effect for the 
downlink TBF(s), the mobile station shall ignore the PACKET UPLINK ASSIGNMENT/ MULTIPLE TBF 
UPLINK ASSIGNMENT message, continue normal operation of the ongoing downlink TBF(s), and reinitiate 
the establishment of the uplink TBF(s) unless the establishment of the uplink TBF(s) has already been attempted 
four times, in which case, the mobile station shall perform the abnormal release with access retry (see sub- 
clause 8.7.2 and 3GPP TS 44.160). 

- If a mobile station in dual transfer mode or MAC-DTM state receives a PACKET UPLINK ASSIGNMENT or a 
MULTIPLE TBF UPLINK ASSIGNMENT message including the Frequency Parameters information element, 
the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 

3GPPTS 44.160). 

- If a failure in the PACKET UPLINK ASSIGNMENT or in the MULTIPLE TBF UPLINK ASSIGNMENT 
message is due to any other reason, the mobile station shall perform an abnormal release with access retry (see 
sub -clause 8.7.2). 

- If the information in the PACKET TIMESLOT RECONFIGURE or in the MULTIPLE TBF TIMESLOT 
RECONFIGURE message does not properly specify a set of uplink and downlink PDCH(s) or violates the 
mobile station's multislot capabilities, the mobile station shall perform an abnormal release with access retry 
(see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If the PACKET TIMESLOT RECONFIGURE or the MULTIPLE TBF TIMESLOT RECONFIGURE message 
does not include a correct UPLINK_TFI_ASSIGNMENT field, then the mobile station shall perform an 
abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 
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- If a mobile station in dual transfer mode receives a PACKET TIMESLOT RECONFIGURE or a MULTIPLE 
TBF TIMESLOT RECONFIGURE message including the Frequency Parameters information element, the 
mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

- If a failure in the PACKET TIMESLOT RECONFIGURE or in the MULTIPLE TBF TIMESLOT 
RECONFIGURE message is due to any other reason, the mobile station shall perform an abnormal release with 
access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

If the failure is due to any other reason, the mobile station shall abort the procedure and perform an abnormal 
release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

If both the mobile station and the network support multiple TBF procedures and if any given uplink assignment 
message provides an uplink TBF allocation for a PFI not indicated in the request for uplink TBF sent by the 
mobile station , the mobile station shall abort the procedure and perform an abnormal release with access retry 
(see sub-clause 8.7.2 and 3GPP TS 44.160). 

8.1.2.6 (void) 

8.1.2.7 (void) 

8.1 .2.8 Network initiated abnormal release of downlinl< TBF 

The network may initiate immediate abnormal release of a downlink TBF by transmitting a PACKET TBF RELEASE 
message to the mobile station on the PACCH. 

The mobile station shall immediately stop monitoring its assigned downlink PDCHs. If a valid RRBP field is received 
as part of the PACKET TBF RELEASE message, the mobile station shall transmit a PACKET CONTROL 
ACKNOWLEDGMENT message in the uplink radio block specified. 

In A/Gb mode, if there are no other on-going TBFs, the mobile station in packet transfer mode shall enter packet idle 
mode; the mobile station in dual transfer mode shall enter dedicated mode. If there is one or more on-going TBFs, the 
mobile station shall remain in its current mode i.e. packet transfer mode or dual transfer mode. The DRX mode 
procedures shall be applied, as specified in sub-clause 5.5.1.5. 

In lu mode, if no on-going TBFs on SBPSCH exist, the mobile station in MAC-Shared state shall enter the MAC-Idle 
State; the mobile station in MAC-DTM state shall enter the MAC -Dedicated state. If any on-going TBFs on SBPSCH 
exist, the mobile station shall remain in its current state, i.e. either MAC-Shared state or MAC-DTM state. The DRX 
mode procedures shall be applied, as specified in 3GPP TS 44.160. 

8.1.3 (void) 

8.1 .4 RLC data block transfer during an MBMS radio bearer 

8.1.4.0 General 

For each MBMS radio bearer, the network shall prioritise RLC/MAC control blocks not containing a 
PACKET DOWNLINK DUMMY CONTROL BLOCK message to be transmitted ahead of RLC data blocks for that 
MBMS radio bearer. If the network has no other RLC/MAC block to transmit, but wishes to transmit on the downlink, 
the network may either follow the procedure specified in sub-clause 9.3.1a, to keep the MBMS radio bearer alive or 
transmit an RLC/MAC control block containing a PACKET DOWNLINK DUMMY CONTROL BLOCK message. 

8.1 .4.1 RLC data blocl^ transfer during an IVIBIVIS radio bearer 

Procedures on receipt of a downlink assignment message (e.g. MBMS ASSIGNMENT message) are specified in sub- 
clause 7.7.2.2. After switching to the assigned PDCHs, the mobile station shall start a T3190 timer instance for the 
corresponding MBMS radio bearer and shall attempt to decode every downlink block on the assigned PDCHs. 

Additionally, upon reception of an MBMS ASSIGNMENT or MBMS MS_ID ASSIGNMENT message assigning a 
specific MS_ID value to a mobile station, this mobile station shall start a T3290 timer instance for the corresponding 
MBMS radio bearer, as specified in sub-clause 7.7.2.4. 
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The mobile station shall restart the related T3190 timer instance whenever receiving a valid RLC/MAC block including 
the assigned MBMS Bearer Identity. In EGPRS TBF mode T3190 is also restarted when receiving an erroneous RLC 
data block for which the header is correctly received and which addresses the mobile station. A mobile station with an 
assigned MS_ID value shall restart the related T3290 timer instance whenever receiving a valid RLC/MAC block 
including the corresponding MBMS Bearer Identity and the MS_ID in the TFI field. 

On expiry of a T3290 timer instance, the mobile station shall consider the MS_ID as released, i.e. it shall no longer 
answer when polled according to sub-clause 8.1.4.2 below. On expiry of a T3190 timer instance, the mobile station 
shall consider the related MBMS radio bearer as released and proceed as specified in sub-clause 7.7.1. 

8.1 .4.2 Polling for MBMS Downlink Acl^NacI^ 

If an uplink feedback channel is established, the network may poll any mobile station with an assigned MS_ID value by 
setting the (E)S/P bit and a valid RRBP field in the RLC/MAC header of an RLC/MAC block for data transfer 
containing both the MBMS Bearer Identity and the corresponding MS_ID value in the TFI field. Whenever a given 
mobile station is polled, the mobile station shall transmit an MBMS DOWNLINK ACK/NACK message in the uplink 
radio block specified by the RRBP field, whatever the BSN value of the received RLC data block. In GPRS TBF mode 
(respectively EGPRS TBF mode), the mobile station shall include the Ack/Nack Description IE (respectively the 
EGPRS Ack/Nack Description IE) in the message. 

The mobile station shall include in the MBMS DOWNLINK ACK/NACK message neighbouring cells measurement 
results as described in sub-clause 5.6.4. In EGPRS TBF mode, the number of measurement reports included is specified 
in sub-clause 9.1.8.2.1. In GPRS TBF mode where cell reselection criteria are not fulfilled three measurement reports 
shall be included. 

In EGPRS TBF mode, the mobile station shall react to a poll within an RLC/MAC block for data transfer if the 
RLC/MAC header is correctly received and addresses the mobile station (i.e. contains both the MBMS Bearer Identity 
and the corresponding MS_ID value in the TFI field) regardless whether the RLC data block(s) is(are) correctly 
received or not. 

The mobile station shall notify, whenever possible, the network of the release of the MS_ID (see note), for that MBMS 
radio bearer, on the mobile station side, by setting the MS_ID Release Indication bit to '1' in the MBMS DOWNLINK 
ACK/NACK message. Any procedure triggering the release of the MS_ID on the mobile station side shall not be 
delayed by such release indication (otherwise such release indication shall not be sent). 

NOTE: The mobile station may need to release the related MBMS session for whatever reason (e.g. due to cell re- 
selection, start of the reception of a higher priority MBMS session whose MBMS radio bearer description 
does not allow the mobile station to receive it in parallel with the current MBMS session, start of a CS 
connection). 

Whenever the network receives a valid RLC/MAC control message containing an assigned MS_ID value, it shall reset 
the counter N3105 for that MS_ID. The network shall increment the counter N3105 for a given MS_ID for each radio 
block, allocated via the polling procedure to the mobile station identified by that MS_ID value, for which no RLC/MAC 
control message is received. If N3105 = N3105_MBMS_MAX, the network shall release the MS_ID (i.e. shall 
internally remove the association between the MS_ID value and the mobile station identified during the MBMS address 
assignment procedure) and start timer T3195 for that MS_ID. When T3195 elapses, the network may reuse the 
corresponding MS_ID value. 

8.1 .4.3 Reconfiguration of an MBMS radio bearer 
8.1 .4.3.1 Individual reassignment of an MS_ID 

The network may modify or delete the MS_ID previously assigned to a given mobile station by sending an MBMS 
MS_ID ASSIGNMENT message on the PACCH/D, containing the current and, in case of a reassignment, the new 
MS_ID value. 

The mobile station shall be addressed with the Global TFI, containing the DOWNLINK_TFI field, which includes the 
MBMS Bearer Identity of the MBMS radio bearer and the current MS_ID of the mobile station the message relates to. 
The size of the new MS_ID, if present, shall be equal to the one of the current MS_ID. If the new MS_ID is present, the 
network may include the Packet Timing Advance IE. 
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When modifying or deleting the current MS_ID, the MBMS MS_ID ASSIGNMENT message shall include a current 
MS_1D expiry time. 

In response to an MBMS DOWNLINK ACK/NACK message with the MS_ID Release Indication bit set to '1' (see 
sub-clause 8.1.4.2), the network may send an MBMS MS_ID ASSIGNMENT message to the mobile station, deleting 
the MS_ID previously assigned to that mobile station on that MBMS radio bearer and setting the current MS_ID expiry 
time to the point in time when the message is transmitted to the mobile station, without further polling the mobile 
station on that MBMS radio bearer. The network shall then start timer T3199 for the current MS_ID. 

Upon reception of an MBMS MS_ID ASSIGNMENT message, modifying or deleting the current MS_ID, the 
addressed mobile station shall consider the current MS_ID as released at the point in time denoted by the current 
MS_ID expiry time. If a new MS_ID is included in the message, the mobile station shall consider the new MS_ID as 
valid and restart timer T3290 at the point in time denoted by the current MS_ID expiry time and react when polled with 
the new MS_ID, according to sub-clause 8.1.4.2. 

If a valid RRBP field is received as part of the MBMS MS_ID ASSIGNMENT message, the mobile station shall 
respond with a PACKET CONTROL ACKNOWLEDGEMENT message in the specified uplink radio block. 

If the network does not receive the PACKET CONTROL ACKNOWLEDGEMENT message in the specified radio 
block, it shall increment counter N3109 for the current MS_ID and may retransmit the MBMS MS_ID ASSIGNMENT 
message addressing the mobile station with the current MS_ID. If counter N3109 = N3109_MAX or at the point in time 
denoted by the current MS_ID expiry time without receiving a PACKET CONTROL ACKNOWLEDGEMENT 
message, whatever occurs first, the network shall start timer T3199 for the current MS_ID. While timer T3199 is 
running for the current MS_ID, the network shall not include the current MS_ID in any RLC/MAC block belonging to 
that MBMS radio bearer. When timer T3199 expires for the current MS_ID, the network may reuse the current MS_ID 
resource. At the point in time denoted by the current MS_ID expiry time the network shall start timer T3199 for the new 
MS_ID, if present. While timer T3199 is running for the new MS_ID, the network shall not include the new MS_ID in 
any RLC/MAC block belonging to that MBMS radio bearer. When timer T3199 expires for the new MS_ID, the 
network may reuse the new MS_ID resource. 

When modifying the current MS_ID, after the point in time denoted by the current MS_ID expiry time, the network 
shall address the mobile station with the new MS_ID, unless counter N3109 for the current MS_ID equals 
N3109_MAX or within the point in time denoted by the current MS_ID expiry time the network has not received a 
PACKET CONTROL ACKNOWLEDGEMENT message from the polled mobile station. 

8.1 .4.3.2 Reassignment of the MBMS Bearer Identity 

The network may reassign the MBMS Bearer Identity previously assigned to a given MBMS radio bearer by sending an 
MBMS ASSIGNMENT (NON-DISTRIBUTION) message on the PACCH/D, including the current MBMS Bearer 
Identity (in the most significant bit(s) of the DOWNLINK_TFI field contained in the Global TFI), explicitly redefining 
(i.e. modifying the length and/or value of) such MBMS Bearer Identity and implicitly deleting or redefining MS_IDs 
assigned to that MBMS radio bearer as described below. 

When reassigning the MBMS Bearer Identity the network shall not reuse the TFI values including the old MBMS 
Bearer Identity in the most significant bit(s) of the TFI field. 

If the mobile station receives more than one MBMS ASSIGNMENT (NON-DISTRIBUTION) message for a given 
MBMS radio bearer, it shall act upon the most recently received message and shall ignore the previous message. 

If a valid RRBP field is received as part of the MBMS ASSIGNMENT (NON-DISTRIBUTION) message, the mobile 
station identified by the corresponding MS_ID shall respond with a PACKET CONTROL ACKNOWLEDGEMENT 
message in the specified uplink radio block. 

Any redefinition of an MBMS Bearer Identity and any deletion or redefinition of MS_IDs shall apply at the point in 
time denoted by the MBMS radio bearer starting time, if present, and immediately otherwise: 

if the new MBMS Bearer Identity field has the same length as the current one all previously assigned MS_ID 
values shall be considered still valid; 

if the new MBMS Bearer Identity field is x bits shorter than the current one, all previously assigned MS_ID 
values shall be implicitly redefined by adding x most significant bits set to zero and shall be considered all valid; 

if the new MBMS Bearer Identity field is x bits longer than the current one, all previously assigned MS_ID 
values characterized by their x most significant bits equal to zero shall be implicitly redefined by removing these 
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X most significant bits and still considered valid. All other assigned MS_ID values shall be considered as invalid 
and discarded. 

At the point in time denoted by the MBMS radio bearer starting time, if present, and immediately otherwise, a mobile 
station shall restart timer T3190 for the newly assigned MBMS Bearer Identity. The mobile station shall restart timer 
T3190 whenever receiving an RLC/MAC block including the new MBMS Bearer Identity. If timer T3190 expires, the 
mobile station shall consider the MBMS radio bearer as released and proceed as specified in sub-clause 7.7.1. At the 
point in time denoted by the MBMS radio bearer starting time, if present, and immediately otherwise, a mobile station 
with an assigned MS_ID value shall start timer T3290. The mobile station shall restart timer T3290 whenever receiving 
an RLC/MAC block including both the new MBMS Bearer Identity and the new MS_ID in the TFI field. 

The following table illustrates the definition of the new MS_ID upon reassignment of the MBMS Bearer Identity: 
Table 8.1.4.3.2.1 : Reassignment of MBMS Bearer Identity and MSJD 



New 
Current 


Bearer 
ID 


MSJD 


Bearer 
ID 


MSJD 


Bearer 
ID 


MSJD 


Bearer 
ID 


MSJD 


Bearer 
ID 


MSJD 


Bearer 
ID 


MSJD 


5 bits 


- 


4 bits 


1 bit 


3 bits 


2 bits 


2 bits 


3 bits 


1 bit 


4 bits 


5 bits 


- 


No MSJD 


New MSJDs 
available 


New MSJDs 
available 


New MSJDs 
available 


New MSJDs 
available 


4 bits 


1 bit 


Discard current 
MSJD 


Keep current 
MS_ID 


x^ Ox 

New MSJDs 

available 


x-^ OOx 

New MSJDs 

available 


X -^ OOOx 

New MSJDs 

available 


3 bits 


2 bits 


Ox-^ X 
1x -^ Discard 
current MS ID 


Keep current 
MSJD 


XX -^ Oxx 

New MS_IDs 
available 


XX -> OOxx 

New MSJDs 

available 


2 bits 


3 bits 


OOx^ X 

Other -^ Discard 

current MS ID 


Oxx -^ XX 
1xx -^ Discard 
current MS ID 
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MSJD 


XXX -^ Oxxx 

New MSJDs 

available 


1 bit 


4 bits 


OOOx -^ X 

Other -^ Discard 

current MS ID 


OOxx -^ XX 

Other -^ Discard 

current MS ID 


OXXX -^ XXX 

1xxx -^ Discard 
current MS ID 


Keep current 
MSJD 


NOTE: The following notations are used: 

"No MS_ID": no IVIS_ID available. MS is not allowed to use feedback 

"Discard current l\/IS_ID": MS shall discard the current MS_ID. MS is no longer allowed to use feedback 

"New MSJDs available": MS_IDs are made available for incoming MSs 

"Keep current MS ID": MS shall keep its current MS ID and use feedback (i.e. reply when polled with this 

MS_ID) 

n ^ m: current MS ID -^ new MS ID. Defines the value of the new MS ID based on the value of the current 

MS_ID 

"x" -^ "x" means the same bit value is used 



The network shall start timer T3191 at the point in time denoted by the MBMS radio bearer starting time, if present, and 
immediately otherwise. When timer T3191 expires the network may reuse the TFI values corresponding to the old 
MBMS Bearer Identity, i.e. the TFI values including the old MBMS Bearer Identity in the most significant bit(s) of the 
TFI field. 



8.1.4.3.3 



Resource reassignment for an MBMS radio bearer 



The network may initiate resource reassignment for an MBMS radio bearer by sending the MBMS ASSIGNMENT 
(NON-DISTRIBUTION) message, including the MBMS Bearer Identity (in the most significant bit(s) of the 
DOWNLINK_TFI field contained in the Global TFI), on the PACCH/D of the MBMS radio bearer. During the 
reassignment of the MBMS radio bearer its associated MBMS Bearer Identity may be changed. 

In case of partial or complete overlap between the old and the new resource configuration on the downlink, the MBMS 
Bearer Identity shall be changed. 

If the MBMS Bearer Identity is changed the network shall not reuse the TFI values including the old MBMS Bearer 
Identity in the most significant bit(s) of the TFI field. 

If the mobile station receives more than one MBMS ASSIGNMENT (NON-DISTRIBUTION) message for a given 
MBMS radio bearer, it shall act upon the most recently received message and shall ignore the previous message. 
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If a valid RRBP field is received as part of the MBMS ASSIGNMENT (NON-DISTRIBUTION) message, the mobile 
station identified by the corresponding MS_ID shall respond with a PACKET CONTROL ACKNOWLEDGEMENT 
message in the specified uplink radio block. 

On receipt of an MBMS ASSIGNMENT (NON-DISTRIBUTION) message, and at the point in time denoted by the 
MBMS radio bearer starting time, if present, the mobile station shall switch to the assigned PDCHs. Upon switching to 
the assigned PDCHs the mobile station shall restart timer T3190 for the newly assigned MBMS radio bearer. The 
mobile station shall restart timer T3190 whenever receiving a valid RLC/MAC block belonging to that MBMS radio 
bearer. In EGPRS TBF mode T3190 is also restarted when receiving an erroneous RLC data block for which the header 
is correctly received and which addresses the mobile station. If timer T3190 expires, the mobile station shall consider the 
MBMS radio bearer as released and proceed as specified in sub-clause 7.7.1. Upon switching to the assigned PDCHs, a 
mobile station with an assigned MS_ID value shall restart timer T3290. The mobile station shall restart timer T3290 
whenever receiving an RLC/MAC block including both the MBMS Bearer Identity and the MS_ID in the TFI field. 

With an MBMS ASSIGNMENT (NON-DISTRIBUTION) message the network may explicitly redefine (i.e. modify the 
length and/or value of) the MBMS Bearer Identity of an MBMS radio bearer and implicitly delete or redefine MS_IDs 
assigned to that MBMS radio bearer as specified in sub-clause 8.1.4.3.2. Any redefinition of an MBMS Bearer Identity 
and any deletion or redefinition of MS_IDs shall only be effective as of switching to the assigned PDCHs. 

After resource reassignment the mobile station shall receive system information messages and paging messages on the 
(P)BCCH and the (P)CCCH or on the PACCH of the MBMS radio bearer, depending on the value of the MBMS In- 
band Signalling Indicator information element included in the MBMS ASSIGNMENT (NON-DISTRIBUTION) 
message and on the presence of an assigned MS_ID value. 

The network shall start timer T3191 at the point in time denoted by the MBMS radio bearer starting time, if present, and 
immediately otherwise. When timer T3191 expires the network may reuse the TFI values corresponding to the old 
MBMS Bearer Identity, i.e. the TFI values including the old MBMS Bearer Identity in the most significant bit(s) of the 
TFI field, on the old resource configuration. 

8.1 .4.4 Network initiated release of an IVIBIVIS radio bearer 

The network may initiate the normal or abnormal release of an MBMS radio bearer by transmitting a PACKET TBF 
RELEASE message to the mobile station(s) on the PACCH. 

The following applies when the PACKET TBF RELEASE message is used for releasing an MBMS radio bearer: 

- the Global TFI shall always contain the DOWNLINK_TFI field. The most significant bit(s) of the 
DOWNLINK_TFI field denote(s) the MBMS Bearer Identity of the MBMS radio bearer released by the 

message; 

- the UPLINK_RELEASE field shall be ignored by the mobile station; 

- the DOWNLINK_RELEASE field shall always be set to the value '1' by the network to indicate that the MBMS 
radio bearer is released. 

NOTE: The network may retransmit the PACKET TBF RELEASE message to increase the probability of its 

correct reception. Timer T3191 is (re)started every time the PACKET TBF RELEASE message is sent. 
When timer T3191 expires for the MBMS radio bearer, then the network may reuse all the TFIs related to 
the MBMS radio bearer. 

Upon receipt of a PACKET TBF RELEASE message referring to an MBMS radio bearer the mobile station is 
receiving, the mobile station shall immediately consider the MBMS Bearer Identity, and the MS_ID if assigned, as 
released, and stop timers T3190 and T3290. 

If the mobile station in broadcast/multicast receive mode is not receiving any other MBMS radio bearers, it shall enter 
packet idle mode and apply the DRX mode procedures as specified in sub-clause 5.5.1.5, otherwise it shall remain in 
broadcast/multicast receive mode. 

8.1 .4.5 Suspension/Resumption of the reception of an IVIBIVIS radio bearer 

In case a mobile station that supports multiple TBF procedures suspends the reception of an MBMS radio bearer for 
whatever reason, the mobile station may retain the MBMS bearer description for such MBMS radio bearer until the 
expiry of the T3190 timer instance for the corresponding MBMS radio bearer. The corresponding MBMS bearer 
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description shall be deleted if the mobile station completes a cell reselection or the session duration timer for this 
MBMS session in the mobile station expires. 

When the mobile station returns to packet idle mode or completes the reception of higher mobile station-specific 
priority MBMS session(s), preventing the mobile station from receiving the suspended MBMS session, still remaining 
in broadcast/multicast receive mode, 

if the MBMS bearer description is still stored in the mobile station, then the mobile station may attempt to 
resume the reception of the suspended MBMS session (re-entering broadcast/multicast receive mode if the 
mobile station has previously left it), 

otherwise the mobile station shall repeat the MBMS packet access procedure for the MBMS session, as specified 
in sub-clause 7.7.1, unless the session duration timer for this MBMS session in the mobile station has expired. 

8.1 .5 Multiple MBMS radio bearers 

8.1 .5.1 Transmission of multiple MBMS radio bearers 

On a PDCH on which multiple MBMS radio bearers are multiplexed, the TFI value(s) including an MBMS Bearer 
Identity (in the most significant bit(s) of the TFI field) shall differ from all the other TFI values including any other 
MBMS Bearer Identity (in the most significant bit(s) of the TFI field). 

8.1 .5.2 Reception of multiple MBMS radio bearers 

8.1.5.2.1 General 

The reception of multiple MBMS radio bearers depends on the capabilities of the mobile station. If the mobile station 
supports multiple TBF procedures and MBMS, it shall be able to support the reception of multiple MBMS radio 
bearers. 

In this sub-clause (and sub-clauses 8.1.5.2.2 to 8.1.5.2.7) the priority is mobile station-specific and allows for 
prioritisation between MBMS sessions on a per-mobile station basis. If two or more MBMS sessions have the same 
priority, the mobile station shall perform an implementation-dependent selection of the MBMS session with the highest 
priority so the resulting priorities are distinct for each MBMS session. 

The mobile station shall be able, according to its capabilities, to receive as many MBMS sessions as possible in 
decreasing order of priority, and to transmit MBMS DOWNLINK ACK/N ACK messages (when applicable) for as 
many MBMS sessions as possible in decreasing order of priority. 

NOTE: Depending on the radio resources allocated for the MBMS radio bearers, a mobile station may not be 
capable of transmitting MBMS DOWNLINK ACK/NACK messages on all associated uplink feedback 
channels. 

If a mobile station is receiving multiple MBMS radio bearers and the mobile station has an MS_ID on at least one 
MBMS radio bearer where the network has indicated that system information for the serving cell and paging messages 
are sent on the PACCH/D, then the mobile station shall not read the system information on the (P)BCCH and shall not 
monitor its paging group on the (P)CCCH in parallel to the MBMS radio bearers. 

If a mobile station is receiving multiple MBMS radio bearers and the mobile station has no MS_ID on any of the 
MBMS radio bearers where the network has indicated that system information for the serving cell and paging messages 
are sent on the PACCH/D, then the mobile station shall not read the system information on the (P)BCCH and shall 
monitor its paging group on the (P)CCCH in parallel to the MBMS radio bearers. 

8.1 .5.2.2 Reception of notification of lower priority MBMS session whilst receiving higher 
priority MBMS session(s) 

If the mobile station in broadcast/multicast receive mode receives a notification of a lower priority MBMS session 
which includes the MBMS bearer description: 

if the capabilities of the mobile station allow, the mobile station shall receive that MBMS session in parallel with 
the higher priority MBMS session(s), provided the requirements defined in sub-clause 8.1.5.2.1 are fulfilled; 
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otherwise, the mobile station shall discard the notification. 

If the mobile station in broadcast/multicast receive mode receives a notification of a lower priority MBMS session 
which does not include the MBMS bearer description and requests the counting procedure, the mobile station shall not 
perform the MBMS packet access procedure. 

8.1 .5.2.3 Reception of assignment of lower priority MBMS session whilst receiving higher 

priority MBMS session(s) 

If the mobile station in broadcast/multicast receive mode receives an assignment for a lower priority MBMS session, 
the mobile station shall act upon the assignment provided the requirements defined in sub-clause 8.1.5.2.1 are fulfilled. 



8.1.5.2.4 



Reception of notification of higher priority MBMS session whilst receiving lower 
priority MBMS session(s) 

If the mobile station in broadcast/multicast receive mode receives a notification of a higher priority MBMS session 
which includes the MBMS bearer description, the mobile station shall act upon the MBMS bearer description and 
receive in parallel other lower priority MBMS sessions according to the requirements defined in sub-clause 8.1.5.2.1. 

If the mobile station in broadcast/multicast receive mode receives a notification of a higher priority MBMS session 
which does not include the MBMS bearer description and requests the counting procedure, then the mobile station shall 
suspend the reception of the lower priority MBMS session(s) and perform the MBMS packet access procedure for the 
higher priority MBMS session, as specified in sub-clause 7.7. 1. After performing the MBMS packet access procedure, 
if the MBMS bearer description(s) for the suspended lower priority MBMS session(s) is (are) still stored in the mobile 
station, then the mobile station may attempt to resume the reception of the suspended MBMS session(s) (see sub-clause 
8.1.4.5). 

8.1 .5.2.5 Reception of assignment of higher priority MBMS session whilst receiving lower 
priority MBMS session(s) 

If the mobile station in broadcast/multicast receive mode receives an assignment for a higher priority MBMS session, 
the mobile station shall act upon the assignment and may drop lower priority MBMS sessions following the 
requirements defined in sub-clause 8.1.5.2.1. 

8.1 .5.2.6 Cell change whilst receiving multiple MBMS sessions (with MBMS supported by 
the network in the target cell) 

When the mobile station reselects a new (target) cell, the mobile station shall according to its capabilities: 

first perform fast reception resumption (see sub-clause 8.1.6.2) of as many MBMS sessions as possible in 
decreasing order of priority, for the sessions for which the mobile station has received in the old cell MBMS 
NEIGHBOURING CELL INFORMATION messages containing the MBMS bearer description of these sessions 
in this target cell; 

NOTE 1 : The mobile station shall not perform MBMS packet access procedure for requesting an MS_ID for any 

MBMS session, with an associated uplink feedback channel, whose priority is lower than the priority of at 
least one of the MBMS sessions for which the MBMS bearer description is not known. 

then perform MBMS packet access and establishment procedure as specified in sub-clause 7.7 for the sessions 
for which the MBMS bearer description is not known, in decreasing order of priority. The mobile station shall 
not operate two concurrent MBMS packet access and establishment procedures. 

NOTE 2: The MBMS packet access procedure is performed in passive mode (i.e. the mobile station notifies the 

network in the MBMS SERVICE REQUEST message that it shall not be counted) for any MBMS session 
whose priority is lower than the priority of at least one of the MBMS sessions already resumed. The 
mobile station may then perform MBMS packet access procedure for requesting an MS_ID for the 
remaining MBMS sessions, with an associated uplink feedback channel, following the requirements 
defined in sub-clause 8.1.5.2.1. 

NOTE 3: The mobile station shall not perform an MBMS packet access procedure for an MBMS session, if the 
session duration timer for this MBMS session in the mobile station has expired. 
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8.1 .5.2.7 Resource reassignment for at least one of the received MBMS radio bearers 

If a mobile station is receiving multiple MBMS radio bearers and any of these is reconfigured by the network in a way 
that the reception of all of them is no longer consistent with the capabilities of the mobile station, then the mobile 
station shall continue receiving the highest priority MBMS session and as many as possible of the other MBMS 
sessions, following the requirements defined in sub-clause 8.1.5.2.1. 

8.1 .6 MBMS reception resumption after cell reselection 

8.1 .6.1 Default behaviour 

If a mobile station in broadcast/multicast receive mode reselects a new (target) cell for which it does not have the 
description of (any of) the MBMS radio bearer(s) being allocated in this target cell for the MBMS session(s) the mobile 
station was receiving in the old serving cell, the mobile station shall follow the default behaviour in the target cell, as 
described in this sub-clause. Otherwise, the mobile station shall perform fast reception resumption, as described in sub- 
clause 8.1.6.2. 

In the target cell, the mobile station shall first perform the acquisition of the system information on the (P)BCCH. 

If the GPRS Cell Options IE denotes that the MBMS procedures are supported by the target cell, the mobile station shall 
then perform the MBMS packet access and establishment procedures, as specified in sub-clause 7.7, for the MBMS 
session the mobile station was receiving in the old serving cell. 

In case of reception of multiple sessions, the mobile station shall obey the procedures described in sub-clause 8.1.5.2.6. 

8.1 .6.2 Fast reception resumption 

If a mobile station in broadcast/multicast receive mode reselects a new (target) cell for which it has received the 
description of (at least one of) the MBMS radio bearer(s) being allocated in this target cell for the MBMS session(s) the 
mobile station was receiving in the old serving cell (see sub-clauses 5.5.1.1 and 7.7.3), the mobile station shall perform 
fast reception resumption in the target cell, as described in this sub-clause. Otherwise, the mobile station shall follow 
the default behaviour, as described in sub-clause 8.1.6.1. 

In the target cell, the mobile station shall immediately resume the reception of the MBMS session for which the MBMS 
bearer description is known from the old serving cell, without first performing the acquisition of the system 
information. If the mobile station fails to resume the reception of the MBMS session for any reason and does not have 
any other MBMS bearer description known for any other MBMS session possibly received in the old serving cell, the 
mobile station shall then follow the default behaviour (see sub-clause 8.1.6.1). 

The acquisition of the system information shall be performed simultaneously with the reception of the MBMS session. 
If the network has indicated that the system information for the resumed MBMS session is not sent on the PACCH 
(with the MBMS In-band SignalUng Indicator information element included in the MBMS NEIGHBOURING CELL 
INFORMATION message transmitted in the old serving cell), the mobile station shall perform the acquisition of the 
system information on the (P)BCCH. In this case, the reception of the MBMS session may need to be suspended during 
such acquisition. The mobile station may then attempt to resume the reception of the suspended MBMS session, 
according to the requirements and the procedures described in sub-clause 8.1.4.5. If the network has indicated that the 
system information for the resumed MBMS session is sent on the PACCH, the mobile station shall perform the 
acquisition of the system information on the PACCH, as described in sub-clause 5.5.2.1.3b. 

In case of reception of multiple sessions, the mobile station shall obey the procedures described in sub-clause 8.1.5.2.6. 

8.2 Packet PDCH Release 

The network may broadcast the PACKET PDCH RELEASE message on PACCH to indicate one or more timeslots is 
no longer available for packet data service. 

When a mobile station receives a PACKET PDCH RELEASE message, it shall immediately stop transmitting and 
receiving on all assigned PDCHs, which are indicated as not present in the TIMESLOTS_AVAILABLE field, remove 
those PDCHs from its list of assigned PDCHs. 
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If all of the mobile station's assigned PDCHs are removed from its list of assigned PDCH, and, if at least one uplink 
TBF was in progress, the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2 and 
3GPP TS 44.160). If no uplink TBFs were in progress, the mobile station shall perform an abnormal release without 
retry (see sub-clause 8.7.1). 

If the mobile station has been assigned an uplink control timeslot and the PACKET PDCH RELEASE message releases 
this PDCH, and if at least one uplink TBF was in progress, the mobile station shall perform an abnormal release with 
access retry (3GPP TS 44.160). If no uplink TBFs were in progress, the mobile station shall perform an abnormal 
release without retry (see sub-clause 8.7.1). 

If the current timeslot configuration requires Shifted USE operation (see sub-clause 8.1.1.2.4) and the PACKET PDCH 
RELEASE message modifies the configuration in such a way that Shifted USE operation is no longer required then 
normal USE operation shall apply after a suitable reaction time as defined in 3GPP TS 45.010. 

8.3 Procedure for measurement report sending in Packet 
Transfer mode 

The procedure for NC measurement report sending shall be initiated by the mobile station at expiry of the NC 
measurement report interval timer T3158 (see sub-clause 5.6.1 and 3GPP TS 44.160). At expiry of the timer T3158 the 
mobile station shall restart the timer T3158, perform the measurements and send either the 
PACKET MEASUREMENT REPORT message containing the 'NC measurement report struct' or the 
PACKET ENHANCED MEASUREMENT REPORT message on PACCH. 

Following a downlink TBF establishment, the PACKET MEASUREMENT REPORT or 

PACKET ENHANCED MEASUREMENT REPORT message shall not be sent on the uplink PACCH associated with 

this TBF until two (EGPRS) PACKET DOWNLINK ACK/NACK messages have been sent to the network. 

8.4 Network controlled cell reselection procedure 

A cell reselection is controlled either by the mobile station or by the network. 

When the cell reselection is controlled by the mobile station, the mobile station shall apply the cell reselection 
procedure defined in sub-clause 5.5.1.1 (A/Gb mode) or 3GPP TS 44.160. 

When a cell reselection is initiated by the network for an individual mobile station, the cell change order procedure is 
started by sending a PACKET CELL CHANGE ORDER message to the mobile station on the PCCCH or PACCH. 

The PACKET CELL CHANGE ORDER message contains: 

The characteristics of the new cell that are necessary to identify it (i.e. BSIC + BCCH frequency). 

The NC measurement parameters valid for the mobile station in the new cell (NETWORK_CONTROL_ORDER 
and optionally: NC_NON_DRX_PERIOD, NC_REPORTING_PERIOD_I and NC_REPORTING_PERIOD_T). 

- The IMMEDIATE_REL parameter. 

The CCN_ACTIVE parameter and optionally the CONTAINER_ID referring to the one included in received 
instances of the PACKET NEIGHBOUR CELL DATA message. 

For a multi-RAT mobile station, the PACKET CELL CHANGE ORDER message may contain information on a 3G 
target cell, together with the IMMEDIATE_REL parameter; in the case of UTRAN establishment of UTRAN 
channel(s) and subsequent measurement reporting are defined in 3GPP TS 25.331. 

Upon receipt of the PACKET CELL CHANGE ORDER message the mobile station shall start timer T3174 and apply 
the cell reselection procedure defined in sub-clause 5.5.1.1 {A/Gb mode) or 3GPP TS 44.160, with the additional rule 
that an immediate abort of operation in the old cell may be required by the network through the IMMEDIATE_REL 
field, except for the acknowledgement, by means of a PACKET CONTROL ACKNOWLEDGEMENT message, of a 
valid RRBP field possibly included in the PACKET CELL CHANGE ORDER message. A UTRAN capable mobile 
station ordered to a UTRAN cell shall obey the PACKET CELL CHANGE ORDER message irrespective of whether 
the target cell is known or not known (see 3GPP TS 25.133 and 3GPP TS 25.123). 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 118 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

If the timers related to measurement reporting expire while the reselection procedure has not yet been completed, these 
timers shall be restarted so that the mobile station resumes the measurement reporting procedures once camped on the 
new cell. 

8.4.1 Network controlled cell reselection completion 

The mobile station shall regard the network controlled cell reselection procedure as successfully completed when it has 
performed access and successfully completed contention resolution in the new cell, or the GMM READY timer (see 
3GPP TS 24.008) stops running during the execution of the procedure. The mobile station shall then stop timer T3174. 

NOTE 1 : Access may be performed for the establishment of a dedicated connection or an uplink TBF. 

NOTE 2: If the GMM READY timer stops running, the mobile station shall apply the network controlled cell re- 
selection mode NCO (i.e., cell re-selection using 'normal MS control', see 3GPP TS 45.008). 

8.4.1b (void) 

8.4.2 Abnormal cases 

In the following cases, the mobile station shall determine that the network controlled cell reselection procedure has 
failed: 

The PACKET CELL CHANGE ORDER message commands the mobile station to a frequency in a frequency 
band not supported by the mobile station. Cause: "frequency not implemented". 

The PACKET CELL CHANGE ORDER message is received while the mobile station is not in dual transfer 
mode but a circuit switched connection is on going. Cause: "on-going CS connection". 

- In A/Gb mode, the PACKET CELL CHANGE ORDER message is received and the GMM READY timer (see 
3GPP TS 24.008) is not running (i.e., mobile station in GMM STAND-BY state). Cause, if the GMM READY 
timer has a negotiated value equal to zero: "Forced to the Standby State". Cause, if the GMM READY timer has 
a negotiated value greater than zero: "MS in GMM Standby state". 

- Access is denied in the new cell (i.e., the mobile station receives an IMMEDIATE ASSIGNMENT REJECT, a 
PACKET ASSIGNMENT REJECT or, in a UTRAN cell, an RRC CONNECTION REJECT message). Cause: 
"Immediate Assign Reject or Packet Access Reject on target cell". 

The mobile station is unable to synchronise to the new cell (see 3GPP TS 45.008) or the timer T3174 expires 
before a successful completion of the network controlled cell reselection procedure. Cause: "No response on 
target cell". 

Due to any other reason (e.g. unknown or unsupported target cell information). In this case the MS shall set the 
ARFCN and BSIC fields to the value zero and set the cause to value "frequency not implemented". 

If the mobile station determines that the network controlled cell reselection procedure has failed, the mobile station 
shall stop timer T3174 (if it is still running) and start timer T3176. The mobile station shall return to the old cell, where 
it may trigger a cell update or other GMM specific procedure. In case the mobile station synchronised and attempted to 
access the new cell before returning to the old cell, the mobile station shall trigger a cell update or other GMM specific 
procedure, as appropriate according to the GMM requirements (see 3GPP TS 24.008). 

The mobile station shall send a PACKET CELL CHANGE FAILURE message with the appropriate cause value to the 
network in the old cell and stop timer T3176. The PACKET CELL CHANGE FAILURE message may be sent on 
PACCH when the mobile station is in packet transfer mode or MAC-Shared state. Alternatively, the mobile station may 
initiate random access with access type "single block without TBF establishment" (PCCCH) / "single block packet 
access" (CCCH) and send the PACKET CELL CHANGE FAILURE message using an allocated single uplink block. 

A mobile station shall ignore a PACKET CELL CHANGE ORDER message received while in dual transfer mode 
(refer to in 3GPP TS 44.018). 

If a MS which is UTRAN capable is commanded to a 3G-target cell whose description is in contradiction to the 
UTRAN capabilities of the mobile station, it shall include the UTRAN FDD target cell or UTRAN TDD Target cell IE 
in the PACKET CELL CHANGE FAILURE message. 
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In case the network controlled cell reselection procedure fails and the MS returns to the old cell, the MS shall delete any 
stored NC measurement parameters and revert to the broadcast parameters. 

If the mobile station is unable to synchronise to the old cell (see 3GPP TS 45.008), or if timer T3176 expires, the mobile 
station shall cancel the sending of the PACKET CELL CHANGE FAILURE message and perform an autonomous cell 
re-selection. 

8.5 Measurement Order procedures in Packet Transfer mode 

The network may initiate the measurement order procedure by sending a PACKET MEASUREMENT ORDER 
message on the PACCH to a mobile station in packet transfer mode or in MAC-Shared state. The PACKET 
MEASUREMENT ORDER message overrides a broadcast PSI5 message. 

The PACKET MEASUREMENT ORDER message may also contain the following optional parameters: 

- NC Measurement Parameters (NETWORK_CONTROL_ORDER; NC_NON_DRX_PERIOD; 
NC_REPORTING_PERIOD_I; NC_REPORTING_PERIOD_T; NC_FREQUENCY_LIST); 

Enhanced measurement reporting. 

Upon receipt of the PACKET MEASUREMENT ORDER message, the mobile station shall store the received 
parameters and obey the NETWORK_CONTROL_ORDER as specified in 3GPP TS 45.008 and in sub-clause 5.6. 

8.6 PACKET CONTROL ACKNOWLEDGEMENT 

A PACKET CONTROL ACKNOWLEDGEMENT message shall always be sent in the uplink block specified by the 
corresponding valid RRBP field of a downlink RLC/MAC control block, and not in any other uplink block that may be 
allocated to the mobile station. However the transmission of the PACKET CONTROL ACKNOWLEDGEMENT 
message takes precedence over the transmission of allocated uplink radio blocks or the reception of PCCCH or assigned 
PDTCH radio blocks. If transmission of the PACKET CONTROL ACKNOWLEDGEMENT message would result in 
more than the maximum Tx timeslots per TDMA frame allowed by the multislot class, transmission of the highest 
numbered PDCH(s) shall be omitted. 

8.7 Abnormal cases 
8.7.0 General 

The following abnormal cases apply: 

If the PDCH containing the mobile station's only assigned TAI value is removed, the mobile station shall, if it 
has at least one ongoing uplink TBF, perform an abnormal release with access retry (see sub-clause 8.7.2, 
3GPP TS 44.160), and otherwise shall perform an abnormal release without retry (see sub-clause 8.7.1). 

If the NC Measurement Parameters are sent in more than one instance of the PACKET MEASUREMENT 
ORDER message, the mobile station shall not obey the measurement order until all instances of the message has 
been correctly received. 

If the mobile station receives a Timing Advance Index and a Timing Advance Timeslot Number for one 
direction within a PACKET POWER CONTROL/TIMING ADVANCE message and the corresponding TBF 
does not exist, the Timing Advance Index and the Timing Advance Timeslot Number for that direction shall be 
ignored. 

- While a TBF is in progress, if a mobile station receives a PACKET UPLINK ASSIGNMENT, MULTIPLE TBF 
UPLINK ASSIGNMENT, PACKET UPLINK ACK/NACK, PACKET TIMESLOT RECONFIGURE, 
MULTIPLE TBF TIMESLOT RECONFIGURE or a PACKET CS RELEASE INDICATION message with 
message escape bit indicating EGPRS (resp. GPRS) contents whereas the current TBF mode is GPRS (resp. 
EGPRS), the mobile station shall ignore the message. 
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- While a TBF is in progress, if a mobile station receives a PACKET DOWNLINK ASSIGNMENT message 
without extension message content related to R99 whereas the current TBF mode is EGPRS, the mobile station 
shall ignore the message. 

- While a TBF is in progress, if a mobile station receives a PACKET DOWNLINK ASSIGNMENT message with 
extension message content related to R99 whereas the current TBF mode is GPRS, the mobile station shall 
ignore the EGPRS related information and act as a GPRS MS not supporting EGPRS. 

- In lu mode, if the network receives a PACKET CONTROL ACKNOWLEDGEMENT message with an incorrect 
timeslot in the TN_RRBP field for the given radio block, then the message shall be ignored. 

8.7.1 Abnormal release without retry 

The mobile station shall abort all TBFs on PDCH(s) in progress and report an RLC/MAC failure to upper layers. The 
mobile station in packet transfer mode or MAC-Shared state shall return to packet idle mode or MAC -Idle state; the 
mobile station in dual transfer mode or MAC-DTM state shall return to dedicated mode or MAC -Dedicated state. Upon 
enhanced CS release while in dual transfer mode, on receipt of PACKET CS RELEASE INDICATION message, the 
mobile station shall abort all TBFs in progress and return to packet idle mode when the RR connection is released. 
Upon mobile originated or mobile terminated RR connection establishment, on receipt of IMMEDIATE 
ASSIGNMENT message while in packet transfer mode, the mobile station shall enter dedicated mode. The DRX mode 
procedures shall be applied as specified in sub-clause 5.5.1.5 and 3GPP TS 44.160. 

8.7.2 Abnormal release with access retry 

The mobile station shall abort all TBFs in progress. The mobile station in packet transfer mode shall return to packet 
idle mode and initiate the establishment of one or more new uplink TBFs, using the procedures on CCCH or PCCCH, 
as defined in sub-clause 7.1. 

The mobile station in dual transfer mode shall return to dedicated mode and initiate the establishment of one new uplink 
TBF (if exclusive allocation is used) or one or more new uplink TBFs (if exclusive allocation is not used) using the 
appropriate DTM procedure on the main DCCH, defined in 3GPP TS 44.018. Upon enhanced CS release, on receipt of 
PACKET CS RELEASE INDICATION message, the mobile station shall abort all TBFs in progress and return to 
packet idle mode and initiate the establishment of one or more new uplink TBFs, using the procedures on CCCH or 
PCCCH when the RR connection is released. 

Upon mobile originated or mobile terminated RR connection establishment, on receipt of IMMEDIATE 
ASSIGNMENT message while in packet transfer mode, the mobile station shall enter dedicated mode and initiate the 
establishment of one new uplink TBF (if exclusive allocation is used) or more new uplink TBFs (if exclusive allocation 
is not used) using the appropriate DTM procedure on the main DCCH, as defined in 3GPP TS 44.018. 

In case the mobile station fails to establish a new uplink TBF, the mobile station shall report an RLC/MAC failure to 
upper layers for that TBF. The DRX mode procedures shall be applied, as specified in sub-clause 5.5.1.5. 

8.7.3 Abnormal release with system information 

The mobile station shall abort all of the TBFs indicated in the assignment message containing invalid frequency 
parameter information and proceed as follows: 

If there are no on-going TBFs it shall immediately return to the BCCH and reread all relevant BCCH and 
PBCCH information. 

If the mobile station had one ongoing uplink TBF when the abnormal release occurred, the mobile station shall 
then perform an abnormal release with access retry (see sub-clause 8.7.2 and 3GPP TS 44.160). 

If the mobile station had no ongoing uplink TBFs when the abnormal release occurred, it shall perform an 
abnormal release without retry (see sub-clause 8.7.1). 

Otherwise, the mobile station shall maintain all its ongoing TBFs that were in progress prior to receiving the 
assignment message containing invalid frequency parameter information and provide a failure indication to the 
upper layers associated with the aborted TBFs. 
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8.7.4 Abnormal release with RR connection establishment retry 

The mobile station shall abort all TBFs in progress and report an RLC/MAC failure to upper layers. The mobile station 
in packet transfer mode shall return to the CCCH configuration, enter packet idle mode and initiate the establishment of 
the RR connection as specified in 3GPP TS 44.018. 

8.8 Network Assisted Cell Change procedures 
8.8.1 Neighbour Cell System Information Distribution 

A mobile station in packet transfer mode or in MAC-Shared state may receive neighbouring cell system information for 
GSM neighbouring cells on PACCH. System Information messages are not distributed for 3G neighbouring cells. The 
neighbouring cell system information is contained in one or more instances of the PACKET NEIGHBOUR CELL 
DATA message and the mobile station is addressed by its TFI as follows: 

If a PBCCH is allocated in the neighbouring cell, the instances of the message may contain the PSIl, a consistent 
set of PSI2 and the PSI14 messages. 

If no PBCCH is allocated in the neighbouring cell, the instances of the message may contain the SB, SI13 and, if 
available, SIl messages. If SIl is broadcast in the target cell, the network shall include the SIl message as the 
first SI message contained in the set of PACKET NEIGHBOUR CELL DATA messages, starting from the 
message with CONTAINER_INDEX=0. 

A mobile station, which receives this information shall, independent of NC mode or CCN mode, store the last received 
set of the information for at least one cell. The received system information can then be used for initial access when 
entering the designated neighbour cell. 

All instances of the PACKET NEIGHBOUR CELL DATA message form a complete container for a certain neighbour 
cell. The container is addressed by a container identity (CONTAINER_ID) in each instance and optionally by the 
ARFCN for BCCH and the BSIC of the neighbour cell. The CONTAINER_ID shall then be included in the PACKET 
CELL CHANGE CONTINUE or the PACKET CELL CHANGE ORDER message together with the ARFCN and the 
BSIC. This is in order to map the cell identity to the container identity for which neighbour cell information was 
received in the PACKET NEIGHBOUR CELL DATA messages. If the ARFCN and BSIC are given for a set of 
PACKET NEIGHBOUR CELL DATA messages, it is sufficient to include this information in only one instance in the 
set. 

In order to ensure a consistent distribution and decoding of (P)SI messages contained in PACKET NEIGHBOUR CELL 
DATA messages, the following rules shall apply for PACKET NEIGHBOUR CELL DATA messages with the same 
container identity: 

Whenever the network starts sending a set of PACKET NEIGHBOUR CELL DATA message instances, the first 
PACKET NEIGHBOUR CELL DATA message instance shall be started with CONTAINER_INDEX=0. 

All subsequent instances of a PACKET NEIGHBOUR CELL DATA message set shall be sent in ascending 
order of CONTAINER_INDEX value. For retransmission purposes it is allowed to send a PACKET 
NEIGHBOUR CELL DATA message with the same CONTAINERJNDEX value and the same content more 
than once. 

- Whenever the MS receives a PACKET NEIGHBOUR CELL DATA message instance with 
CONTAINER_INDEX=0 or with a CONTAINER_INDEX value that is less than the CONTAINERJNDEX 
value of the last received PACKET NEIGHBOUR CELL DATA message instance, it shall delete any PACKET 
NEIGHBOUR CELL DATA message instances it may have stored and the extracted system information of the 
neighbour cell. 

- If the MS receives a PACKET NEIGHBOUR CELL DATA message with a different ARFCN and BSIC than 
was indicated in one or more already received PACKET NEIGHBOUR CELL DATA message instances, it shall 
delete any PACKET NEIGHBOUR CELL DATA message instances it may have stored and the extracted 
system information of the neighbour cell. 

- 30 s after the reception of the latest PACKET NEIGHBOUR CELL DATA message instance, the MS shall 
delete any PACKET NEIGHBOUR CELL DATA message instances it may have stored the extracted system 
information of the neighbour cell. 
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When the mobile station receives the PACKET CELL CHANGE ORDER or the PACKET CELL CHANGE 
CONTINUE message the mobile station shall transmit a PACKET CONTROL ACKNOWLEDGMENT message in the 
specified uplink radio block if a valid RRBP field is received as part of the message ; the mobile station may then 
switch to a new cell. If the mobile station has collected all required instances of the PACKET NEIGHBOUR CELL 
DATA message for the new cell already when in the old cell, then it may perform access depending on whether the 
PACKET PSI STATUS (or PACKET SI STATUS if PBCCH is not supported in the new cell) procedures are supported 
by the network in the new cell (see below). The required instances of the PACKET NEIGHBOUR CELL DATA 
message include PSIl, a consistent set of PSI2 messages and PSI14 (if the new cell has a PBCCH allocated) or SB, 
SI13 and, if available, SIl messages (if the new cell does not have a PBCCH allocated). If the MS is able to decode the 
first SI message contained in the set of PACKET NEIGHBOUR CELL DATA messages but it was not the SIl 
message, the MS shall conclude that SIl is not broadcast in that particular cell in determining when packet access is 
allowed in the cell (see sub-clause 5.5.1.3). 

If not all required instances of the PACKET NEIGHBOUR CELL DATA message have been received before the cell 
change, the MS shall first obtain the PBCCH description (if available) and the missing system information messages 
before making initial access in the new cell. However, it may switch to the new cell as soon as PSIl has been received 
(if PBCCH is supported in the new cell) or SI13 has been received (if PBCCH is not supported in the new cell). 

Once all the required system information messages have been received, and if the new cell supports the PACKET PSI 
STATUS (respectively PACKET SI STATUS) procedures, the mobile station may perform access in the new cell and 
shall then use these procedures for acquisition of PSI (respectively SI) messages (see sub-clause 5.5.1.4.3). If the 
PACKET PSI STATUS (respectively PACKET SI STATUS) procedures are not supported by the network in the new 
cell, then the MS is still required to make at least one attempt to receive the complete set of PSI messages on PBCCH 
(respectively make at least one attempt to receive other SI messages that may be scheduled within one TC cycle on 
BCCH) prior to perform access in the new cell (see sub-clauses 5.5.1.2 and 5.5.1.3 and 3GPP TS 44.160). 



8.8.2 CCN setting procedure 



The network uses the parameter CCN_ACTIVE in the GPRS Cell Options IE on the BCCH (SI 13) or PBCCH 
(PSI1/PSI13/PSI14) to indicate in the cell whether CCN is enabled for cell reselection towards GSM cells. 

The network uses the parameter 3G_CCN_ACTIVE on the BCCH (SI2quater) or PBCCH (PSBquater) to indicate in 
the cell whether CCN is enabled for cell reselection towards 3G cells. 

If CCN_ACTIVE is not provided or it indicates that CCN is disabled in the cell, the mobile stations shall not 
follow the CCN procedures towards GSM cells. CCN_ACTIVE can also be individually sent to the mobile 
station in either a PACKET MEASUREMENT ORDER or a PACKET CELL CHANGE ORDER message. In 
the latter case, the setting applies in the target cell. 

If 3G_CCN_ACTIVE is not provided or it indicates that CCN is disabled in the cell, the mobile stations shall not 
follow the CCN procedures towards 3G cells. 3G_CCN_ACTIVE can also be individually sent to the mobile 
station in either a PACKET MEASUREMENT ORDER or a PACKET CELL CHANGE ORDER message. In 
the latter case, the setting applies in the target cell. 

If CCN_ACTIVE indicates that CCN is enabled in the cell and a mobile station determines a cell re-selection 
towards one of its neighbouring GSM cells is required, it shall first check the corresponding CCN_SUPPORTED 
parameter if available. This allows the network to enable CCN mode towards some but not all neighbour GSM 
cells. 

NOTE: It is not possible for the network to enable CCN mode towards individual 3G neighbour cells. 

An individual setting of CCN shall take precedence over the broadcast setting of CCN. The latest individual ordered 
setting of CCN is the valid one. An individual setting of CCN is only valid within the cell it is ordered for. CCN is 
applicable to a mobile station in Network Control mode NCO and NCI but not in mode NC2 that takes precedence over 
CCN. 



8.8.2a CCN support description 



The CCN Support description contains the CCN_SUPPORTED parameter for each GSM cell of the GSM Neighbour 
Cell list. 

If there is no PBCCH allocated in the cell, see 3GPP TS 44.018. 
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If there is a PBCCH allocated in the cell, the parameter can be provided in the PSI3 message or any instance of the 
PSBbis message. In that case, the bitmap applies to the GSM Neighbour Cell list having the same 
PSI3_CHANGE_MARK as the message in which it is provided. 

CCN_SUPPORTED parameter can also be provided in a PACKET CELL CHANGE ORDER or a PACKET 
MEASUREMENT ORDER message. In this case, the bitmap applies to the updated GSM Neighbour Cell list. 

Each CCN_SUPPORTED bit of this description relates to indices of the GSM Neighbour Cell list, starting with index 0. 
The CCN Support description may be received before the corresponding GSM Neighbour Cell list. 

Indices exceeding the value 95 or the number of cells in the GSM Neighbour Cell list (whichever is the lowest) shall be 
ignored. If there are fewer indices than the number of cells in the GSM Neighbour Cell list, the value shall be 
assumed for the missing bits. 

When this information is not present but CCN is enabled in the serving cell, the mobile station shall assume that CCN is 
enabled towards all neighbour cells. 

8.8.3 Cell Change Notification procedure 

If CCN is enabled towards the target cell (see sub-clause 5.5.Lla and 3GPP TS 44.160), the mobile station shall behave 
as in network control mode NCO or NCI up to the point when a new cell has been chosen. If the target cell is a GSM 
cell, the mobile station shall then check the CCN_SUPPORTED parameter, if available, that was last received for that 
cell. This parameter can be sent on BCCH or PBCCH or individually in PACKET MEASUREMENT ORDER or 
PACKET CELL CHANGE ORDER or PS HANDOVER COMMAND messages. 

If for a GSM cell the CCN_SUPPORTED parameter is available and if it indicates that CCN mode shall not be entered 
towards that cell, then the mobile station shall perform the cell change and not enter CCN mode. If the cell reselection is 
triggered by the path loss criterion parameter CI becoming negative, the mobile station may perform the cell change 
without entering the CCN mode. 

If the target cell is a GSM cell and the CCN_SUPPORTED parameter is available and if it indicates that CCN mode 
shall be entered towards that cell or if the CCN_SUPPORTED parameter is not available, then instead of performing 
the cell change, the mobile station shall start timer T3206 and enter the CCN mode. At the first possible opportunity, the 
MS shall then, when in CCN mode, inform the network about the proposed target cell by sending a PACKET CELL 
CHANGE NOTIFICATION message, stop timer T3206, start timers T3208 and T3210. 

If the target cell is a 3G cell and if CCN is activated towards 3G cells, then instead of performing the cell change, the 
mobile station shall start timer T3206 and enter the CCN mode. At the first possible opportunity, the MS shall then, 
when in CCN mode, inform the network about the proposed target cell by sending a PACKET CELL CHANGE 
NOTIFICATION message, stop timer T3206, start timers T3208 and T3210. 

The PACKET CELL CHANGE NOTIFICATION message shall contain the identity of the proposed target cell. A 
GSM cell shall be identified by the ARFCN for the BCCH and the BSIC. A 3G-FDD cell shall be identified by 
FDD_ARFCN, Bandwidth_FDD and Scrambling code. A 3G-TDD cell shall be identified by TDD_ARFCN, 
Bandwidth_TDD, Cell parameter and Scrambling Code. 

The PACKET CELL CHANGE NOTIFICATION message shall also contain measurement reports for the proposed cell 
and for the six other strongest and allowed (see 3GPP TS 45.008) neighbour cells, if available. If 3G Neighbour cells 
are reported, the type of report for FDD cells are specified by the FDD_REP_QUANT parameter and the number of 3G 
reports in the message are specified by the parameters FDD_MULTIRAT_REPORTING and 
TDD_MULTIRAT_REPORTING. These parameters may either be broadcast on BCCH or PBCCH or sent to the 
mobile station in a PACKET MEASUREMENT ORDER or PACKET CELL CHANGE ORDER message. 

In CCN mode the mobile station shall continue the data transfer and store neighbour cell system information if received 
in instances of the PACKET NEIGHBOUR CELL DATA message, but not perform the cell change. At receipt of the 
first PACKET NEIGHBOUR CELL DATA message or PACKET CELL CHANGE CONTINUE message or PACKET 
CELL CHANGE ORDER message or PS HANDOVER COMMAND message, the mobile station shall stop the timer 
T3210. 

The mobile station shall retransmit the PACKET CELL CHANGE NOTIFICATION message once at the first possible 
opportunity when the timer T3210 expires. 

The mobile station shall leave CCN mode when either CCN is no longer enabled (towards all GSM or 3G neighbour 
cells with the CCN_ACTIVE/3G_CCN_ACTIVE bit or towards the cell that had been re-selected) or when the network 
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has responded with a PACKET CELL CHANGE CONTINUE or PACKET CELL CHANGE ORDER message or a PS 
HANDOVER COMMAND message or when either of the timers T3206 or T3208 have expired. 

If the mobile station has been individually ordered to enable CCN, the order is only valid within the cell where the order 
is given. When a cell change has been performed using the cell reselection procedure, the mobile station shall use CCN 
in the new cell only if individually ordered in the previous cell with the PACKET CELL CHANGE ORDER message or 
if individually ordered or broadcast in the new cell. When a cell change has been performed using the PS handover 
procedure, the mobile station shall enable CCN in the new cell only if individually ordered in the previous cell with the 
PS HANDOVER COMMAND message or if individually ordered or broadcast in the new cell. 

After receiving a PACKET CELL CHANGE NOTIFICATION message from the mobile station the network can 
behave in different ways as described below. 

1) The network responds with a PACKET CELL CHANGE CONTINUE message. 

If a mobile station as response to a PACKET CELL CHANGE NOTIFICATION message receives a PACKET 
CELL CHANGE CONTINUE message without receiving any neighbour cell system information, the mobile 
station shall stop timer T3208, stop timer T3210 if still running, leave CCN mode and continue cell reselection 
in NCO/NCl mode. 

2) The network sends first necessary system information for the cell proposed in the PACKET CELL CHANGE 
NOTIFICATION message if the proposed target cell is a GSM cell in one or more instances of the PACKET 
NEIGHBOUR CELL DATA message and sends then a PACKET CELL CHANGE CONTINUE message. 
The mobile station shall store the received system information as specified in sub-clause 8.8.1. When the first 
instance of the PACKET NEIGHBOUR CELL DATA message is received, the mobile station shall stop timer 
T3210 if still running. When the PACKET CELL CHANGE CONTINUE message is received, the mobile 
station shall stop timer T3208, leave CCN mode and continue the cell reselection in NCO/NCl mode irrespective 
of the cell indicated in the ARFCN and BSIC parameters in the PACKET CELL CHANGE CONTINUE 
message. 

3) The network sends first necessary system information for the cell proposed in the PACKET CELL CHANGE 
NOTIFICATION message if the proposed target cell is a GSM cell, or for any other GSM cell, in one or more 
instances of the PACKET NEIGHBOUR CELL DATA message and sends then a PACKET CELL CHANGE 
ORDER message or a PS HANDOVER COMMAND message. 

The mobile station shall store the received system information as specified in sub-clause 8.8.1. When the first 
instance of the PACKET NEIGHBOUR CELL DATA message is received, the mobile station shall stop timer 
T3210 if still running. When the PACKET CELL CHANGE ORDER message is received, the mobile station 
shall stop timer T3208, leave CCN mode and follow the procedures as specified for the PACKET CELL 
CHANGE ORDER message (sub-clause 8.4) and in sub-clause 8.8.1. When the PS HANDOVER COMMAND 
message is received, the mobile station shall stop timer T3208, leave CCN mode and follow the procedures as 
specified for the PS HANDOVER COMMAND message in sub-clause 8.10.4. 

4) The network orders the mobile station into NC2 mode. 

A mobile station may in response to a PACKET CELL CHANGE NOTIFICATION message receive a PACKET 
MEASUREMENT ORDER message from the network indicating NC2 mode. When the mobile station receives 
the NC2 order it shall leave CCN mode, stop timer T3208, stop timer T3210 if still running, and go into NC2 
mode. 

When the NC2 mode has been ordered, the network may send PACKET NEIGHBOUR CELL DATA messages 
on the PACCH before sending the PACKET CELL CHANGE ORDER message to the mobile station. When the 
NC2 mode has been ordered, the network shall send PACKET NEIGHBOUR CELL DATA messages on the 
PACCH before sending the PS HANDOVER COMMAND message (see sub-clause 8.10.2) to the mobile 
station. 

5) No network response 

When timer T3210 expires, the mobile station shall retransmit once the PACKET CELL CHANGE 
NOTIFICATION message at the first possible opportunity. 

When timer T3208 expires, the mobile station shall leave CCN mode and continue cell reselection in NCO/NCl 
mode as described in sub-clause 5.5.1.1 and 3GPP TS 44.160 and in 3GPP TS 45.008. 

The CCN mode is only valid in packet transfer mode or in MAC-Shared state. If the mobile station is in CCN mode 
when entering packet idle mode or MAC -Idle state, the mobile station shall stop the timers T3206 and T3208, stop 
timer T3210 if still running, leave CCN mode and continue the cell reselection procedure according to the NCO/NCl 
procedures. If PACKET NEIGHBOUR CELL DATA messages are received on the PACCH before entering packet idle 
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mode or MAC-Idle state and the cell identity parameters are included, this information may then be used at the next cell 
change. 

If the cell reselection criteria have changed during the time the MS is in CCN mode but the path loss criterion parameter 
CI remains positive, the MS shall, without notifying the network about the new preferred cell, remain in CCN mode 
until the criteria for CCN mode are no longer fulfilled. When leaving CCN mode the MS shall obey the new criteria 
according to the normal rules as specified in sub-clause 5.5.1.1 and 3GPP TS 44.160 and in 3GPP TS 45.008 unless a 
PACKET CELL CHANGE ORDER or a PS HANDOVER COMMAND message has been received (see bullet 3 
above). If the path loss criterion parameter CI becomes negative while the MS is in CCN mode, the MS may leave the 
CCN mode without notifying the network and perform the cell change. 

8.9 RR connection establishment in packet transfer mode 

8.9.0 General 

The initiation of the procedure and the assignment of resources for the establishment of the RR connection are 
described in sub-clauses 8.9.1 and 8.9.2, respectively. 

The establishment of the main signalling link and the completion of the establishment of the RR connection are 
described in 3GPP TS 44.018. 

8.9.1 Initiation 

8.9.1 .1 Initiation by the mobile station 

8.9.1 .1 .1 Transmission of the PACKET CS REQUEST message 

The RR connection establishment procedure is initiated by the RR entity of the mobile station. Initiation is triggered by 
request from the MM sublayer to enter dual transfer mode. The request from the MM sublayer to establish the RR 
connection specifies an establishment cause. 

The RR entity in the mobile station shall not request the establishment of an RR connection while in packet transfer 
mode from the point where it receives a PS HANDOVER COMMAND message until the PS handover procedure has 
been completed (see sub-clause 8.10). 

On receipt of the RR connection establishment request from upper layer the mobile station shall start timer T3196. At 
expiry of timer T3196, the mobile station shall release all ongoing TBFs and start RR connection establishment as 
specified in 3GPP TS 44.018. If a mobile station that supports PS handover receives a PS HANDOVER COMMAND 
message while T3196 is running it shall stop T3196, abort its current attempt to establish an RR connection and not 
make another attempt to establish an RR connection until completion of the PS handover procedure. 

If the contention resolution is not solved, the mobile station shall delay the transmission of the PACKET CS REQUEST 
message until contention resolution is solved. 

If the countdown procedure has been started on all the ongoing uplink TBFs, none of those TBFs is operating in 
extended uplink TBF mode and there is no downlink TBF in progress, the mobile station may either send the PACKET 
CS REQUEST message, or may immediately release the ongoing TBF(s) and start an RR connection establishment as 
specified in 3GPP TS 44.018. 

The mobile station shall initiate the RR connection establishment by sending PACKET CS REQUEST messages on the 
PACCH. The mobile station is allowed to retransmit the PACKET CS REQUEST message once while timer T3196 is 
running. The second sending occurrence of this message shall take place at the first suitable opportunity at least 0.75 s 
after the first transmission of that message. 

8.9.1.1.2 Answer from the network 

Upon receipt of a PACKET CS REQUEST message, the network shall answer to the mobile station by encapsulating 
one of the following RR messages in the PACKET CS COMMAND message, and sending the PACKET CS 
COMMAND message on PACCH: 
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- DTM ASSIGNMENT COMMAND message (see sub-clause 8.9.2.1); or 

- IMMEDIATE ASSIGNMENT message (see sub-clause 8.9.2.2); or 

- IMMEDIATE ASSIGNMENT REJECT message (see sub-clause 8.9.2.3). 

Upon receipt of PACKET CS COMMAND message encapsulating one of the above messages the mobile station shall 
stop timer T3 196. 

8.9.1 .2 Initiation by the network 

The network initiates the RR connection establishment procedure by sending a PACKET CS COMMAND message to 
the mobile station on PACCH, encapsulating one of the following RR messages: 

- DTM ASSIGNMENT COMMAND message (see sub-clause 8.9.2.1); or 

- IMMEDIATE ASSIGNMENT message (see sub-clause 8.9.2.2). 

After sending the mobile station a PS HANDOVER COMMAND message the network shall not initiate the 
establishment of an RR connection for that mobile station until the PS handover procedure has been completed (see 
sub-clause 8.10). 

8.9.2 Assignment 

8.9.2.1 Assignment of both dedicated and packet resource 

The network may allocate both a dedicated channel and radio resources on one or more PDCHs to be used by the 
mobile station and shall in this case send a DTM ASSIGNMENT COMMAND encapsulated in a PACKET CS 
COMMAND message. Having sent the DTM ASSIGNMENT COMMAND message, the network starts timer T3107, 
specified in 3GPP TS 44.018. The allocated dedicated channel shall be of TCH type. The network may also reallocate 
radio resources (PDCH(s)) in the DTM ASSIGNMENT COMMAND message. If both the RR Packet Uplink 
Assignment and the RR Packet Downlink Assignment information elements are omitted in the DTM ASSIGNMENT 
COMMAND the network implicitly indicates that the current radio resources shall be maintained. The mobile station 
shall act on the DTM ASSIGNMENT COMMAND message as specified in 3GPP TS 44.018. 

On receiving an encapsulated DTM ASSIGNMENT COMMAND message, the mobile station shall establish the main 
signalling link using the procedure described in 3GPP TS 44.018. 

The completion of the establishment of the RR connection is described in 3GPP TS 44.018. 

If timer T3107 elapses before the successful establishment of the main signalling link on the new channel, both the new 
CS channel and new PS resources are released. If the encapsulated DTM ASSIGNMENT COMMAND message was 
sent in response to a PACKET CS REQUEST message received from the mobile, then the old PS resources are also 
released. 

NOTE: If timer T3 107 expires and the procedure was initiated by the network, the subsequent network behaviour 
with respect to the old PS resources is implementation dependent. 

8.9.2.2 Assignment of dedicated resource only 

The network may allocate only a dedicated channel to the mobile station and shall in this case send an IMMEDIATE 
ASSIGNMENT encapsulated in a PACKET CS COMMAND message. Having sent the IMMEDIATE ASSIGNMENT 
message, the network starts timer T3101, specified in 3GPP TS 44.018. 

If a mobile station receives an encapsulated IMMEDIATE ASSIGNMENT message which either does not specify a 
starting time or specifies a starting time which has already elapsed, the mobile station shall immediately: 

perform an abnormal release without retry (see sub-clause 8.7.1), if no uplink TBF is in progress, or, 

perform an abnormal release with access retry (see sub-clause 8.7.2), if one or more uplink TBFs are in progress. 

On receiving an encapsulated IMMEDIATE ASSIGNMENT message which specifies a starting time which has not yet 
elapsed, the mobile station shall wait until the specified start time. If, at that time, no uplink TBF is in progress, the 
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mobile station shall perform an abnormal release without retry (see sub-clause 8.7.1); else (i.e. one or more uplink TBFs 
are in progress) the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2). 

The mobile station shall proceed with the assignment by establishing the main signalling link using the procedure 
described in 3GPP TS 44.018. In respect of the RR connection, the mobile station shall act on the starting time 
information element, if present, as specified in 3GPP TS 44.018. 

The completion of the establishment of the RR connection is described in 3GPP TS 44.018. 

If timer T3101 elapses before the main signalling link is established, the new CS channel is released. If the encapsulated 
IMMEDIATE ASSIGNMENT message was sent in response to a PACKET CS REQUEST message received from the 
mobile, the old PS resources are also released. 

NOTE: If timer T3 101 expires and the procedure was initiated by the network, the subsequent network behaviour 
with respect to the old PS resources is implementation dependent. 

8.9.2.3 Rejection of the mobile station request 

If no dedicated channel is available for assignment, the network may send to the mobile station an IMMEDIATE 
ASSIGNMENT REJECT message encapsulated in a PACKET CS COMMAND message. 

On receipt of the encapsulated IMMEDIATE ASSIGNMENT REJECT message the mobile station shall stop sending 
PACKET CS REQUEST messages, starts timer T3122 with the indicated value ("wait indication" information element, 
specified in 3GPP TS 44.018) and continue in packet transfer mode. 

The behaviour of the mobile station while timer T3122 is running is specified in 3GPP TS 44.018. 

8.9.3 (void) 

8.9.4 Abnormal cases 

8.9.4.1 RR connection establishment initiated by the mobile station 

If a failure occurs on the mobile station side before the successful establishment of the main signalling link, the 
allocated channels are released; the subsequent behaviour of the mobile station depends on the type of failure and 
previous actions: 

If the radio resources have been dropped before the network has a chance to respond to the PACKET CS 
REQUEST, the network shall abort the current DTM procedure. 

If the mobile station does not receive the PACKET CS COMMAND message after it has sent a corresponding 
PACKET CS REQUEST message (i.e. expiry of timer T3196), the mobile station shall perform an abnormal 
release with the RR connection establishment retry (see sub-clause 8.7.4). 

- If the mobile station receives the DTM ASSIGNMENT COMMAND or the IMMEDIATE ASSIGNMENT 
message specifying frequencies that are not all in one frequency band then the mobile station shall perform an 
abnormal release with RR connection establishment retry (see sub-clause 8.7.4). 

- If the mobile station receives the DTM ASSIGNMENT COMMAND or the IMMEDIATE ASSIGNMENT 
message containing a Frequency Parameters information element specifying a frequency that is in a frequency 
band not supported by the mobile station then the mobile station shall perform an abnormal release with RR 
connection establishment retry (see sub-clause 8.7.4). 

- If the information in the DTM ASSIGNMENT COMMAND message does not properly specify an uphnk PDCH 
or violates the mobile station's multislot capabilities, the mobile station shall perform an abnormal release with 
RR connection establishment retry (see sub-clause 8.7.4). 

- If the information in the DTM ASSIGNMENT COMMAND message does not properly specify an uplink and 
downlink PDCH or violates the mobile station's multislot capabilities, the mobile station shall perform an 
abnormal release with RR connection establishment retry (see sub-clause 8.7.4). 
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- If a failure in the assignment message (e.g. DTM ASSIGNMENT COMMAND or the IMMEDIATE 
ASSIGNMENT message) is due to any other reason, the mobile station shall perform an abnormal release with 
RR connection establishment retry (see sub-clause 8.7.4). 

If the mobile fails to establish the main signalling link, it shall perform an abnormal release with RR connection 
establishment retry (see sub-clause 8.7.4). 

8.9.4.2 RR connection establishment initiated by the network 

If a failure occurs on the mobile station side before the successful establishment of the main signalling link, the 
allocated channels are released; the subsequent behaviour of the mobile station depends on the type of failure and 
previous actions: 

- If the information in the DTM ASSIGNMENT COMMAND message does not properly specify an uphnk PDCH 
or violates the mobile station's multislot capabilities, the mobile station shall perform an abnormal release with 
access retry (see sub-clause 8.7.2). 

- If the information in the DTM ASSIGNMENT COMMAND message does not properly specify an uplink and 
downlink PDCH, the mobile station shall perform an abnormal release with access retry (see sub-clause 8.7.2). 

If the mobile station has been reassigned a TBF in EGPRS TBF mode and the MS does not support EGPRS, or 
has been reassigned an MCS (e.g. 8-PSK in the uplink) that the MS does not support, the MS shall enter to 
dedicated mode and notify higher layers (TBF establishment failure). 

On expiry of timer T3 190, the mobile station shall enter dedicated mode. 

- If a failure in the DTM ASSIGNMENT COMMAND message is due to any other reason, the mobile station 
shall return to packet idle mode. 

If there is a failure in the IMMEDIATE ASSIGNMENT message the mobile station shall continue in packet 
transfer mode. 

If the mobile fails to establish the main signalling link, it shall perform an abnormal release with RR connection 
establishment retry (see sub-clause 8.7.4). 

8.1 Packet Switched Handover procedure 

8.10.1 General 

This procedure is only applicable in packet transfer mode when both the mobile station and the network support PS 
handover. The support of PS handover procedures requires the support of PFC procedures in both the network and the 
mobile station. In packet transfer mode, a mobile station that supports PS handover may receive a PS HANDOVER 
COMMAND message from the BSS indicating the resources to be used in the new cell. 

The support of the PS handover procedures is optional for the mobile station and the network and is indicated in the MS 
Radio Access Capability IE. A mobile station supporting the PS handover procedures shall also support the extended 
RLC/MAC control message segmentation as defined in 9.1.12a. 

8.10.2 Neighbour Cell System Information Distribution 

For the case of PS handover from A/Gb mode to A/Gb mode the network shall send the mobile station PACKET 
NEIGHBOUR CELL DATA messages containing PSI messages (PBCCH allocated in new cell) or SI messages 
(PBCCH not allocated in new cell) corresponding to the new cell prior to sending it the PS HANDOVER COMMAND 
message directing it to that cell. PACKET NEIGHBOUR CELL DATA messages are received on PACCH as described 
in sub-clause 8.8. 1 . The minimum set of SI and PSI messages to be sent in PACKET NEIGHBOUR CELL DATA 
messages is as follows: 

If PBCCH is not allocated in the new cell then SB, SIl (if present in the new cell) and SI13 shall be sent. 

If PBCCH is allocated in the new cell then PSIl, a consistent set of PSI2 messages and PSI14 shall be sent. 
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For the case of PS handover from lu mode to A/Gb mode the network shall send the mobile station the same set of PSI 
messages or SI messages corresponding to the new cell as for the case of PS handover from A/Gfe mode to A/Gb mode. 
In this case the network sends the mobile station the system information corresponding to the new cell within the 
Handover from UTRAN Command message as described in 3GPP TS 25.331 and 3GPP TS 44.1 18. 

For the case of PS handover from A/Gb mode to lu mode, system information corresponding to the new cell is sent to 
the mobile station in the new cell as described in 3GPP TS 25.331 and 3GPP TS 44.118. 

8.1 0.3 PS Handover at the network side 

8.10.3.1 Initiation of PS Handover Procedure 

The source BSS may initiate the PS handover procedure as a result of various trigger conditions such as, but not 
restricted to, the following: 

Upon receiving a measurement report or a PACKET CELL CHANGE NOTIFICATION message from a mobile 
station operating in A/Gb mode. 

Upon determining that resource limitations exist for the serving cell. 

Upon receiving the Service UTRAN CCO IE from the SGSN indicating that a mobile station operating in A/Gb 
mode would be better served in a cell supporting a different RAT. 

If the mobile station is not already in NC2 then the source BSS may order the mobile station to enter NC2 before 
initiating the PS handover procedure. For the normal case of PS handover the target RNC/BSS receives a network 
request to allocate resources required to perform a PS handover. For the optimized case of PS handover (applicable only 
for A/Gb mode to A/Gb mode PS handover - see 3GPP TS 43.129) an SGSN request for the BSS to allocate resources is 
not required as the resources required to perform a PS handover are allocated autonomously by the BSS (i.e. without 
SGSN involvement). 

8.1 0.3.2 A/Gb to A/Gb PS Handover 

For both the normal and optimized cases of PS handover from A/Gb mode to /^Gb mode the (source) BSS shall impose 
the following restrictions on RLC/MAC control plane corresponding to a mobile station for which the PS handover 
procedure is ongoing: 

All mobile station requests to establish new uplink TBFs shall be ignored and no new downlink TBFs shall be 
established. 

- The PS HANDOVER COMMAND message shall be sent using extended RLC/MAC control message 
segmentation (see sub-clause 9.1.12a) if three or more RLC/MAC control blocks are required to send the 
complete message. 

After sending the PS HANDOVER COMMAND to the MS, the source BSS shall continue to schedule opportunities for 
the mobile station to transmit an RLC/MAC control message, either by means of an existing uplink TBF, or by means 
of polling using an existing downlink TBF, for a period of time sufficiently long to allow the mobile station to transmit 
a PACKET CELL CHANGE FAILURE message (should a PS handover failure occur). During this period, the BSS 
may allocate fewer transmission opportunities than would otherwise be required according to the QoS requirements of 
the ongoing PFCs. No TBFs shall be released during this period except on receipt of a DELETE-BSS-PFC PDU from 
the SGSN. 

For both the normal and optimized cases of PS handover from A/Gb mode to A/Gb mode the (target) BSS creates a 
complete PS HANDOVER COMMAND message that is sent to the mobile station in the old cell: 

For the normal case of PS handover the source BSS shall send the Page Mode, Global TFI and Container ID 
information elements to the target BSS which uses them to create a complete PS HANDOVER COMMAND message 
(see sub-clause 11.2.41). 

For the normal case of PS handover the source BSS receives a complete PS HANDOVER COMMAND message from 
the target BSS (passed through the SGSN) and then sends it to the mobile station. For the optimized case of PS 
handover the BSS creates a complete PS HANDOVER COMMAND message and sends it directly to the mobile 
station. 
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If the PS HANDOVER COMMAND indicates RLC reset for a TBF allocated in the new cell corresponding to a PFC 
receiving a PS handover, the target BSS shall initialize a new RLC entity to support that TBF. Otherwise, the TBF 
allocated in the new cell shall be supported using the same RLC entity used to support the TBF in the old cell 
corresponding to the same PFC (i.e. the RLC state machine is maintained across PS handover). 

The PS HANDOVER COMMAND message created by the target BSS shall always allocate resources for at least one 
uplink TBF to ensure that the mobile station can send PS HANDOVER ACCESS messages (if required) and one or 
more RLC data blocks in the new cell. When only one uplink TBF is allocated by the PS HANDOVER COMMAND 
message and does not correspond to a PFC, RLC acknowledged mode shall be used. 

The PS HANDOVER COMMAND message created by the target BSS shall indicate the PS Handover type with the 
synchronization indication field, i.e. non-synchronized, synchronized or pre-synchronized PS handover. 

The target BSS expects one or more PS HANDOVER ACCESS messages from the mobile station whenever Handover 
Reference information is included in the PS HANDOVER COMMAND message. Handover Reference information 
shall always be included whenever non-synchronized PS handover is used. 

The PS HANDOVER COMMAND shall contain the PFI for each TBF being set up if and only if both the network and 
the mobile station support multiple TBFs. A mobile station which receives a PS HANDOVER COMMAND and which 
does not support multiple TBFs shall ignore any PFI value(s) received in the PS HANDOVER COMMAND. 

Depending on the type of handover the target BSS shall proceed as follows: 

In case of a synchronized or pre-synchronized PS handover the target BSS shall enable the reception of RLC 
data blocks on all upUnk TBFs allocated by the PS HANDOVER COMMAND message. 

In case of a non-synchronized PS handover the target BSS shall, upon reception of the first PS HANDOVER 
ACCESS message containing the expected Handover Reference value, send the PACKET PHYSICAL 
INFORMATION message to the mobile station and then enable the reception of RLC data blocks on all uplink 
TBFs allocated by the PS HANDOVER COMMAND message. 

The BSS should schedule USFs on at least one uplink TBF in the target cell to minimize the delay incurred by 
the mobile station waiting for a USE in the target cell. 

The target BSS considers the PS handover procedure to be successfully completed upon receiving the first correct 
uplink RLC block on any of the uplink TBFs allocated to the mobile station in the PS HANDOVER COMMAND 

message. 

If the target BSS supports blind transmission it may begin transmitting downlink data that becomes available prior to 
determining that the PS handover procedure has been successfully completed. Otherwise, it may discard downlink data 
that becomes available prior to determining that the PS handover procedure has been successfully completed. 

8.1 0.3.3 GERAN A/Gb to UTRAN PS Handover 

For the case of PS handover from A/Gb mode to UTRAN the source BSS proceeds as described above for the normal 
case of A/Gb mode to A/Gb mode PS handover except for the following: 

The source BSS shall create a complete PS HANDOVER COMMAND message using local values for the Page 
Mode, Global TFI and Container ID information elements and therefore shall not send these information 
elements to the target RNC. 

The source BSS receives a complete Handover to UTRAN Command message from the target RNC (passed 
through the SGSN) and sends it to the mobile station within a PS HANDOVER COMMAND message. 

- The source BSS shall not send the mobile station unsolicited PACKET NEIGHBOUR CELL DATA messages 
in the old cell as system information corresponding to the new cell is sent to the mobile station in the new cell as 
described in 3GPP TS 25.331 and 3GPP TS 44.1 18. 

8.1 0.3.4 lu to GERAN A/Gb PS Handover 

For the case of PS handover from lu mode to A/Gb mode the target BSS proceeds as described above for the normal 
case of A/Gb mode to A/Gb mode PS handover except that a complete PS HANDOVER COMMAND message is 
created by the target BSS using local values for the Page Mode, Global TFI and Container ID information elements (i.e. 
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they are not passed to the target BSS from the source RNC) and the PS HANDOVER COMMAND message shall 
always indicate RLC reset for each PFC and non-synchronized PS handover. 

8.1 0.4 PS Handover at the mobile station side 
8.1 0.4.1 A/Gb to A/Gb PS Handover 

Upon reception of the PS HANDOVER COMMAND message for PS handover from A/Gb mode to A/Gb mode, the 
mobile station shall proceed as follows: 

- If an RLC/MAC control block containing a part of the PS HANDOVER COMMAND message contains a valid 
RRBP field or a polling response is outstanding the mobile station shall send a corresponding PACKET 
CONTROL ACKNOWLEDGMENT message (in the specified uplink radio block) prior to switching to the new 
cell. 

RLC/MAC control plane signalling shall be suspended except for the signalling needed to complete the PS 
handover procedure or to signal a failure of the PS handover procedure. 

The mobile station shall suspend the uplink transmission of user plane data. 

Each outstanding request for establishment or reconfiguration of an uplink TBF in the old cell shall be aborted 
and the corresponding instance of T3168 shall be stopped. 

All timers related to the RLC contexts in the old cell keep running. 

Timers T3180 and T3190 related to the ongoing TBFs in the old cell and which are currently running shall be re- 
started. 

If the timer T3 192 related to a TBF in the old cell expires, the mobile station shall consider the corresponding 
TBF that was ongoing in the old cell as implicitly released. 

The mobile station shall start timer T3218, move to the new cell and perform the physical channel establishment 
as described in sub-clause 8.10.4.4.: 

The mobile station may receive downlink RLC data blocks in the new cell prior to determining that the PS 
handover has been successfully completed if the target BSS uses blind transmission. If this occurs the mobile 
station shall forward the corresponding user data to upper layers if the PS HANDOVER COMMAND message 
did not include the NAS Container for PS Handover IE. Otherwise, the mobile station may either discard the 
received RLC data blocks or buffer them until the successful completion of the PS handover procedure at which 
point the corresponding user data shall be deciphered by the upper layers based on information contained within 
the NAS Container for PS Handover IE. 

NOTE: It is expected that PS Handover procedure will be completed successfully or terminated before the expiry 
of T3180 or T3190 and therefore that the MS will not release any TBFs due to the expiry of T3180 or 
T3190 during the PS Handover procedure. The mobile station considers the PS handover procedure to be 
successfully completed in the following cases: 

Upon receiving a PACKET PHYSICAL INFORMATION message in the new cell in case of a non-synchronized 
PS handover (see sub-clause 8.10.4.4.3). 

Upon detecting the first USE for any uplink TBF assigned to the MS in the new cell in case of a synchronized 
and pre-synchronized PS handover (see subclause 8.10.4.4.1 and 8.10.4.4.2). 

If the mobile station is waiting for the PACKET PHYSICAL INFORMATION message when it receives a downlink 
RLC data block in which a valid polling indication is provided, it shall ignore the polling indication. 

Upon successfully completing the PS handover procedure the mobile station shall proceed as follows: 

Stop T3216 (if running), consider all TBFs that were ongoing in the old cell as implicitly released and if the NAS 
Container for PS Handover IE was included in the PS HANDOVER COMMAND message it shall be sent to 
upper layers. 

- If the PS HANDOVER COMMAND indicates RLC reset the mobile station shall initialize new RLC entities to 
support the allocated TBFs. Otherwise, the TBFs allocated in the new cell shall be supported using the same 
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RLC entities used to support the TBFs in the old cell corresponding to the same PFCs (i.e. the RLC state 
machines are maintained across PS handover). 

The mobile station shall resume the uplink transmission of user plane data. 

The mobile station shall trigger a cell update or other GMM specific procedures, as appropriate according to the 
GMM requirements (see 3GPP TS 24.008). 



8.1 0.4.2 A/Gb to UTRAN PS Handover 

Upon receiving a PS HANDOVER COMMAND message for PS handover from GERAN A/Gb mode to UTRAN, the 
mobile station shall act on the message if it is able to perform PS handover based on the content of the received 
message. If the PS HANDOVER COMMAND message is acted on the mobile station shall start the PS handover 
procedure and proceed as described above for the case of A/Gb mode to A/Gb mode PS handover while in the old cell. 
Upon moving to the new cell the mobile station shall proceed as described in 3GPP TS 25.331. Upon successfully 
completing the PS handover procedure all TBFs that were ongoing in the old cell shall be considered as implicitly 
released. 

8.1 0.4.3 lu to A/Gb PS Handover 

Upon receiving a Handover from UTRAN Command message for PS handover from lu mode to A/Gb mode, the mobile 
station shall act on the message if all of the following conditions are satisfied: 

It is able to perform PS handover based on the content of the received message. 

The Handover from UTRAN Command message contains the minimum set of PSI or SI messages required for 
mobile station to operate in the new cell (see sub-clause 8.10.4.1.). 

- The PS HANDOVER COMMAND message carried within the Handover from UTRAN Command message 
provides resources for at least one uplink THE in the new cell. 

If the Handover from UTRAN Command message is acted on the mobile station shall start the PS handover procedure 
and proceed as follows: 

The mobile station shall act as described in 3GPP TS 25.331 and 3GPP TS 44. 118 prior to switching to the new 
cell except for the following: 

It shall ignore the value of the Page Mode, Global TFI and Container ID information elements included in the 
PS HANDOVER COMMAND message carried within the Handover from UTRAN Command message. 

After switching to the new cell the mobile station shall proceed as described above for the case of A/Gb mode to 
A/Gb mode PS handover except for the following: 

Upon successfully completing the PS handover procedure the mobile station shall stop T3216 (if running), 
consider all radio bearers that were ongoing in the old cell as implicitly released, send the NAS Container for 
PS Handover IE to upper layers if it was included in the PS HANDOVER COMMAND message, start an 
instance of T3180 corresponding to each uplink TBF allocated by the PS HANDOVER COMMAND 
message and start an instance of T3190 corresponding to each downlink TBF allocated by the PS 
HANDOVER COMMAND message. 

Upon successfully completing the PS handover procedure the mobile station shall always establish a new 
RLC entity for each TBF allocated by the PS HANDOVER COMMAND message. 

8.10.4.4 Physical channel establishment 
8.10.4.4.1 General 

Three procedures are defined. The support of them is mandatory in the mobile station. 

If the network requests the transmission of the PS HANDOVER ACCESS message it shall be sent with highest 
transmission priority using either the 8-bit or 11 -bit access burst format on the PACCH associated with any uplink TBF 
allocated in the PS HANDOVER COMMAND message for which the mobile station detects an assigned USE value. Its 
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content consists of the handover reference field. The burst format used shall be that specified by the 
ACCESS_BURST_TYPE in the system information for the target cell. 

Upon detecting the first USF for any uplink TBF assigned to the MS in the new cell, the MS shall stop T3218. 

8.10.4.4.2 Synchronized cell case 

If the timing advance with the new cell calculated by the mobile station is not out of range, i.e. smaller than or equal to 
the maximum timing advance that can be coded as specified in 3GPP TS 44.004, or if the new cell does accept out of 
range timing advance as indicated in the PS HANDOVER COMMAND message, the mobile station acts on the 
message. 

After having switched to the assigned channels, if the Handover Reference information is included within the PS 
HANDOVER COMMAND message the mobile station shall send four times the PS HANDOVER ACCESS message. 

The mobile station activates the channels in sending and receiving mode resume the operation in packet transfer mode. 
The MS may activate the channels in downlink while sending access bursts. 

8.10.4.4.3 Pre-synchronized cell case 

The details of the use of this procedure are described in 3GPP TS 45.010. 

After having switched to the assigned channels, if the Handover Reference information is included within the PS 
HANDOVER COMMAND message the mobile station shall send four times the PS HANDOVER ACCESS message. 

The mobile station activates the channels in sending and receiving mode. The MS may activate the channels in 
downlink while sending access bursts. 

The timing advance value to be used with the new cell is: 

either the value contained in the PS HANDOVER COMMAND message if the timing advance information is 
included; or 

the default value for pre-synchronized handover as defined in 3GPP TS 45.010, if the timing advance 
information element is not included in the PS HANDOVER COMMAND message. 

8.10.4.4.4 Non synchronized cell case 

After having switched to the assigned channels, the mobile station shall send four times the PS HANDOVER ACCESS 
message. The mobile station shall start timer T3216 at the start point of the timeslot in which the PS HANDOVER 
ACCESS message is sent the first time on the PACCH. 

The mobile station then activates the channels in receiving mode. 

Upon reception of the PS HANDOVER ACCESS message containing the expected Handover Reference value, once the 
network has the RF characteristics that are necessary, it shall send a PACKET PHYSICAL INFORMATION message 
to the mobile station on the PACCH. 

When the mobile station receives a PACKET PHYSICAL INFORMATION message, it stops timer T3216, stops 
sending access bursts and activates the channels in sending and receiving mode. 

8.10.5 Abnormal Cases 

8.1 0.5.1 MS Behaviour for A/Gb to A/Gb PS Handover 

A mobile station operating in A/Gb mode shall consider the PS handover to A/Gb mode to have failed if the PS 
HANDOVER COMMAND message: 

contains an invalid Frequency Parameters information element; or 

contains specifying frequencies that are not all in one frequency band; or 
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contains a Frequency Parameters information element specifying a frequency that is in a frequency band not 
supported by the mobile station; or 

does not properly specify an uplink or downlink PDCH or violates the mobile station's multislot capabilities; or 

does not provide resources for at least one uplink TBF in the new cell; or 

contains any other failure. 

A mobile station operating in A/Gb mode shall consider the PS handover to A/Gb mode to have failed for the following 
reasons: 

In the synchronized cell case (see sub-clause 8.10.4.4.1), if the timing advance with the new cell calculated by 
the mobile station is out of range, i.e. is bigger than the maximum timing advance that can be coded as specified 
in 3GPP TS 44.004, and if the new cell does not accept out of range timing advance as indicated in the PS 
HANDOVER COMMAND message. 

If it has not stored a valid minimum set of the following of PSI or SI messages (provided via PACKET 
NEIGHBOUR CELL DATA messages, see sub-clause 8.8.1) required for mobile station to operate in the new 
cell: PSIl, a consistent set of PSI2 messages and PSI14 (if PBCCH allocated in the new cell) or SI3, SIl (if 
present in the new cell) and SI13 messages (if PBCCH not allocated in the new cell). 

Timer T3218 expires while in the new cell. 

Timer T3216 expires while in the new cell. 

A mobile station operating in A/Gb mode when a PS handover to A/Gb mode fails shall proceed as follows: 

- If timer T3218 expired it shall return to the cell on which the PS HANDOVER COMMAND message was 
received. 

- If timer T3216 expired it shall return to the cell on which the PS HANDOVER COMMAND message was 
received. 

- Send a PACKET CELL CHANGE FAILURE message with the cause code set to "No response on target cell" if 
timer T3218 or T3216 expired, otherwise "PS Handover failure-others". The message shall be sent on PACCH. 

The transmission of a PACKET CELL CHANGE FAILURE message terminates the PS handover procedure in 
the mobile station and after the transmission of this message the mobile station is therefore allowed to request 
the establishment of additional uplink TBFs. 

After terminating the PS handover procedure the mobile station shall resume all uplink and downlink TBFs that 
were ongoing in the old cell prior to receiving the PS HANDOVER COMMAND message. Timers T3180 
(uplink TBFs) and T3190 (downlink TBFs) corresponding to these TBFs shall be re-started. 

For each TBF that is resumed the corresponding RLC state machine shall reflect its state when the last RLC data 
block was transmitted for that TBF in the old cell (uplink TBFs) and the last RLC data block was received for 
that TBF in the old cell (downlink TBFs). 

8.1 0.5.2 MS Behaviour for A/Gb to UTRAN PS Handover 

A mobile station operating in A/Gb mode shall consider PS handover to lu mode to have failed if it is unable to perform 
PS handover for any reason based on the content of the received PS HANDOVER COMMAND message. 

A mobile station operating in A/Gb mode when a PS handover to lu mode fails shall proceed as described above for the 
case where PS handover from PsJGb mode to A/Gb mode fails except that T3216 shall never be running. 

8.1 0.5.3 MS Behaviour for lu to A/Gb PS Handover 

A mobile station operating in lu mode shall consider PS handover to A/Gb mode to have failed for the following 
reasons: 

It is unable to perform PS handover for any reason based on the content of the received Handover from UTRAN 
Command message. 
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The Handover from UTRAN Command message does not contain the minimum set of PSI or SI messages 
required for mobile station to operate in the new cell (see sub-clause 8.10.4.1.)- 

Timer T3218 expires while in the new cell. 

Timer T3216 expires while in the new cell. 

- The PS HANDOVER COMMAND message carried within the Handover from UTRAN Command message 
does not provide resources for at least one uplink TBF in the new cell. 

A mobile station operating in lu mode when a PS handover to A/Gb mode fails shall return to the cell it was in prior to 
receiving the Handover from UTRAN Command message (if T3216 or T3218 expired) and proceed as described in 
3GPPTS 25.331 and 3GPPTS 44.118. 

8.1 0.5.4 BSS Behaviour for PS Handover from A/Gb 

The source BSS shall terminate the PS handover procedure if any of the following events occur: 

All TBFs allocated to the mobile station in the old cell are released at any point prior to sending the PS 
HANDOVER COMMAND message to the mobile station. 

- The source BSS receives a PACKET CELL CHANGE FAILURE message or any other RLC block from the 
mobile station after sending the final segment of the PS HANDOVER COMMAND message, if the network 
does not request acknowledgement of receipt of that segment (i.e. does not include in any segment a valid RRBP 
field requiring the mobile station to send a PACKET CONTROL ACKNOWLEDGEMENT message), or after 
the receipt of a PACKET CONTROL ACKNOWLEDGEMENT message indicating that the mobile station has 
received the final segment of the PS HANDOVER COMMAND message. 

If the PS handover procedure is terminated for either of the above reasons, the (source) BSS shall resume all uplink and 
downlink TBFs that were ongoing in the old cell for that MS prior to sending the PS HANDOVER COMMAND 
message. For normal PS Handover the source BSS shall then indicate the PS handover failure to the SGSN. For 
optimized PS Handover the source BSS shall then release all resources associated with the new TBFs. 

For each TBF that is resumed the corresponding RLC state machine shall refiect its state when the last RLC data block 
was transmitted for that TBF in the old cell (downlink TBFs) and the last RLC data block was received for that TBF in 
the old cell (uplink TBFs). 

For both the normal and optimized cases of PS Handover, after sending the PS HANDOVER COMMAND to the MS, 
the source BSS shall continue to schedule transmission opportunities for the mobile station for a period of time 
sufficiently long to allow the mobile station to transmit a PACKET CELL CHANGE FAILURE message (should a PS 
handover failure occur). 

For normal PS Handover, if the source BSS does not receive any RLC/MAC block from the MS and does not receive 
(a) DELETE-BSS-PFC PDU(s) from the SGSN for all ongoing PFCs during this time period, the source BSS shall 
consider radio contact with the MS to be lost and shall release all resources related to the MS and initiate the PS 
Handover Cancel procedure (see 3GPP TS 48.018), by sending a PS-HANDOVER-CANCEL PDU to the SGSN with 
cause "Radio contact lost with MS". 

For optimized PS Handover, if the BSS does not receive any RLC/MAC block from the MS on any of the old TBFs and 
does not receive an uplink RLC data block from the MS on any of the new TBFs during this time period, the BSS shall 
consider the MS to be lost and therefore release all resources associated with the new TBFs and old TBFs. 

8.1 0.5.5 BSS Behaviour for PS Handover to A/Gb 

If the (target) BSS expects but does not receive any PS HANDOVER ACCESS messages from the mobile station it 
considers the PS handover procedure to have failed and shall release all TBFs allocated to the mobile station in the new 
cell. 

If the (target) BSS expects but does not receive the correct Handover Reference value from the mobile station it 
considers the PS handover procedure to have failed and shall release all TBFs allocated to the mobile station in the new 
cell. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 136 ETSI TS 144 060 V6.28.0 (2010-03) 

9 Radio Link Control (RLC) procedures in packet 

transfer mode 

9.0 General 

The RLC function is responsible for: 

Interface primitives allowing the transfer of upper layer PDUs between the upper layer and the MAC function. 

- Segmentation of upper layer PDUs into RLC data blocks and re-assembly of RLC data blocks into upper layer 
PDUs. 

Segmentation of RLC/MAC control messages into RLC/MAC control blocks and re-assembly of RLC/MAC 
control messages from RLC/MAC control blocks. 

Backward Error Correction (BEC) procedures enabling the selective retransmission of RLC data blocks. 

In this sub-clause Packet Ack/Nack refers to any of the following messages: 

- PACKET DOWNLINK ACK/NACK, EGPRS PACKET DOWNLINK ACK/NACK or MBMS DOWNLINK 
ACK/NACK. 

- PACKET UPLINK ACK/NACK. 
Additionally the following definitions apply: 

- Sequence Number Space (SNS): 2048 in EGPRS, and 128 in GPRS. 

- Window Size (WS): 64 to 1024 in EGPRS; 64 in GPRS. 

A mobile station that supports multiple TBF procedures can operate multiple RLC entities simultaneously each one 
with its' own set of RLC parameters (e.g. sequence number; receive and transmit windows etc.). 

9.1 Procedures and parameters for peer-to-peer operation 

A TBF is comprised of two peer entities, which are the RLC endpoints. Each RLC endpoint has a receiver that receives 
RLC/MAC blocks. Each RLC endpoint also has a transmitter that transmits RLC/MAC blocks. 

An MBMS bearer is comprised of one transmitting RLC endpoint at the network side and several receiving RLC 
endpoints, one for each mobile station involved in the p-t-m transmission. The transmitting RLC endpoint transmits 
RLC/MAC data and control blocks and may receive only RLC/MAC control blocks. Each receiving RLC endpoint 
receives RLC/MAC data and control blocks and may transmit only RLC/MAC control blocks, upon polling. An MBMS 
bearer operates in RLC non-persistent mode (see also sub-clause 9.3.4). 

Each endpoint's receiver has a receive window of size WS (see sub-clause 9.1.9). 

In RLC acknowledged mode, the receive window is defined by the receive window state variable V(Q) in the following 
inequality[ V(Q) < BSN < V(Q)h- WS ] modulo SNS (for the method of interpreting inequalities in this format refer to 
sub-clause 9.1.8). All BSNs which meet that criteria are valid within the receive window. 

In RLC unacknowledged mode, all values of BSN are within the receive window. 

In RLC non-persistent mode, the receive window is determined after recalculating the receive state variable V(R) (as 
described in sub-clause 9.1.5) and the corresponding receive window state variable V(Q) (as described in sub-clause 
9.1.6). All BSNs which meet the following inequality [ V(Q) < BSN < V(R)] modulo SNS are valid within the receive 
window. 

An RLC data block is considered received, when it is received in a layer 1 frame with consistent parity bits (in EGPRS 
TBF mode: header and relevant data parity bits) and correctly addresses the receiving RLC endpoint. 
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Each endpoint's transmitter has a transmit window of size WS. In RLC acknowledged mode and in RLC non-persistent 
mode, the transmit window is defined by the send state variable V(S) in the following inequality: [ V(A) < 
BSN < V(S) ] modulo SNS, where [ V(S) - V(A) ] modulo SNS < WS. All BSNs which meet that criteria are valid 
within the transmit window. In RLC unacknowledged mode, all values of BSN are within the transmit window. 

9.1.1 Send state variable V(S) 

Each RLC endpoint transmitter shall have an associated send state variable V(S). V(S) denotes the sequence number of 
the next in-sequence RLC data block to be transmitted. V(S) can take on the value through SNS - 1 . V(S) shall be set 
to the value at the beginning of each TBF in which the RLC endpoint is the transmitter. The value of V(S) shall be 
incremented by 1 after transmission of the RLC data block with BSN = V(S). In RLC acknowledged mode, V(S) shall 
not exceed V(A) modulo SNS by more than the maximum allowed number of outstanding RLC data blocks WS. In 
RLC non-persistent mode, V(S) may be incremented independently on the value of V(A). 

9.1.1a Control send state variable V(CS) 

The network RLC endpoint transmitter shall have one instance of an associated control send state variable V(CS) for 
each parallel control transaction identified by the RTI field of the RLC/MAC control block header. V(CS) denotes the 
sequence number of the next in-sequence RLC/MAC control block to be transmitted for the control transaction. V(CS) 
can take on the values or 1 when RLC/MAC control message segmentation into two RLC/MAC control blocks is 
used, and the values to 8 when extended RLC/MAC control message segmentation is used (see sub-clause 9.L12a). 
V(CS) shall be set to the value prior to the transmission of each RLC/MAC control block that contains the first octet 
of an RLC/MAC control message of the control transaction and the value of V(CS) shall be set to 1 after the 
transmission of the RLC/MAC control block with RBSN = 0. The value of V(CS) shall then be incremented by 1, when 
extended RLC/MAC control message segmentation is used, after the transmission of the next in-sequence RLC/MAC 
control block and so on. 

9.1 .2 Acknowledge state variable V(A) 

In RLC acknowledged mode, each RLC endpoint transmitter shall have an associated acknowledge state variable V(A). 
V(A) contains the BSN value of the oldest RLC data block that has not been positively acknowledged by its peer. V(A) 
can take on the values through SNS - L V(A) shall be set to the value at the beginning of each TBF in which the 
RLC endpoint is the transmitter. The value of V(A) shall be updated from the values received from its peer in the 
received block bitmap (RBB) of the Packet Ack/Nack message (see sub-clause 9. L8) 

Furthermore, [ V(S) - V(A) ] modulo SNS < WS. 

In RLC non-persistent mode, each RLC endpoint transmitter shall have an associated acknowledge state variable V(A). 
V(A) contains the BSN value of the oldest RLC data block that has not yet been positively acknowledged by all the 
peers. V(A) can take on the values through SNS - I. V(A) shall be set to the value at the beginning of each MBMS 
bearer in which the RLC endpoint is the transmitter. The value of V( A) shall be updated from the values received from 
its peers in the received block bitmap (RBB) of the MBMS DOWNLINK ACK/NACK message (see sub-clause 9.L8). 
V(A) shall be set to BSN', where BSN' is the BSN value of the oldest RLC data block not yet positively acknowledged 
by all the peers which meets the condition [V(S) - BSN'] modulo SNS < WS, or it shall be set to V(S) if all RLC data 
blocks have been positively acknowledged by all the peers. 

9.1 .3 Acknowledge state array V(B) 

9.1 .3.1 Acknowledge state array V(B) for GPRS TBF Mode 

In RLC acknowledged mode, each RLC endpoint transmitter shall have an associated acknowledge state array (V(B)). 
V(B) is an array of SNS elements indicating the acknowledgement status of WS previous RLC data blocks. The array is 
indexed relative to the acknowledge state variable V(A) modulo SNS. The values of V(B) shall be updated from the 
values received from its peer in the received block bitmap (RBB) of the Packet Ack/Nack message (see sub-clause 
9.L8) 

The transmitter shall transmit the oldest RLC data block whose corresponding element in V(B) indexed relative to V(A) 
has the value NACKED. As each RLC data block is transmitted the corresponding element in V(B) is set to the value 
PENDING_ACK. 
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If [ V(S) < V(A) + WS ] modulo SNS and no RLC data blocks have a corresponding element in V(B) with the value 
NACKED, the RLC data block with BSN = V(S) shall be transmitted and the corresponding element in V(B) shall be 
set to the value PENDING_ACK. If there are no further RLC data blocks available for transmission (i.e. the RLC data 
block with BSN= V(S) does not exist), the sending side shall transmit the oldest RLC data block whose corresponding 
element in V(B) has the value PENDING_ACK, then the next oldest block whose corresponding element in V(B) has 
the value PENDING_ACK, etc. If all RLC data blocks whose corresponding element in V(B) has the value 
PENDING_ACK have been transmitted once, the process shall be repeated beginning with the oldest RLC data block. 

If V(S) = V(A) + WS modulo SNS (i.e. the transmit window is stalled), the sending side shall transmit the oldest RLC 
data block whose corresponding element in V(B) has the value PENDING_ACK, then the next oldest RLC data block 
whose corresponding element in V(B) has the value PENDING_ACK, etc. If all RLC data blocks whose corresponding 
element in V(B) has the value PENDING_ACK has been transmitted once, the process shall be repeated beginning with 
the oldest RLC data block. This process of transmitting the oldest RLC data blocks whose value in V(B) has the value 
PENDING_ACK shall continue, as long as equation [V(S)=V(A)+WS] modulo SNS holds. 

When an element in V(B) falls outside of the active transmit window, i.e. [ V(A) < BSN < V(S) ] modulo SNS, the 
element shall be set to the value INVALID. 

In the extended uplink TBF mode, if V(S) = V(A) and there is no RLC data block with BSN = V(S) available, the 
mobile station shall stop sending RLC data blocks. The mobile station shall continue sending RLC data blocks when a 
RLC data block with BSN = V(S) is available. 

9.1 .3.2 Acknowledge State Array V(B) for EGPRS TBF Mode 

In RLC acknowledged mode, each RLC endpoint transmitter shall have an associated acknowledge state array (V(B)). 
V(B) is an array of SNS elements indicating the acknowledgement status of WS previous RLC data blocks. The array is 
indexed relative to the acknowledge state variable V(A) modulo SNS. The values of V(B) shall be updated from the 
values received from its peer in the reported bitmap (RB) of the Packet Ack/Nack message (see sub-clause 9.L8). If a 
compressed reported bitmap is received, decompression shall be first applied according to sub-clause 9.L10. 

The transmitter shall transmit the oldest RLC data block whose corresponding element in V(B) indexed relative to V(A) 
has the value NACKED. As each RLC data block is transmitted the corresponding element in V(B) is set to the value 
PENDING_ACK. If the RLC data block to be transmitted is split over two radio blocks, both radio blocks shall be 
transmitted. On initial transmission the RLC data blocks are sent with one of the initial code rates (the rate 1/3 encoded 
data is punctured with Puncturing Scheme (PS) 1 of the selected Modulation and Coding Scheme MCS) and if the RLC 
data block is required to be retransmitted it is sent with PS 2 of the selected MCS. On subsequent retransmissions the 
RLC data block is transmitted with PS in a cyclic process (refer to sub-clause 9.3.2.1). 

If [ V(S) < V(A) + WS ] modulo SNS and no RLC data blocks have a corresponding element in V(B) with the value 
NACKED, the RLC data block with BSN = V(S) shall be transmitted and the corresponding element in V(B) shall be 
set to the value PENDING_ACK. If the transmitter is the mobile station, the pre-emptive transmission bit is set to Tin 
the PACKET UPLINK ACK/NACK message and there are no further RLC data blocks available for transmission 
(i.e. the RLC data block with BSN= V(S) does not exist), the sending side shall transmit the oldest RLC data block 
whose corresponding element in V(B) has the value PENDING_ACK, then the next oldest block whose corresponding 
element in V(B) has the value PENDING_ACK, etc. If all RLC data blocks whose corresponding element in V(B) has 
the value PENDING_ACK have been transmitted once, the process shall be repeated beginning with the oldest RLC 
data block. 

If [V(S) = V(A) + WS] modulo SNS (i.e. the transmit window is stalled), the sending side shall transmit the oldest RLC 
data block whose corresponding element in V(B) has the value PENDING_ACK, then the next oldest RLC data block 
whose corresponding element in V(B) has the value PENDING_ACK, etc. If all RLC data blocks whose corresponding 
element in V(B) has the value PENDING_ACK has been transmitted once, the process shall be repeated beginning with 
the oldest RLC data block. This process of transmitting the oldest RLC data blocks whose value in V(B) has the value 
PENDING_ACK shall continue as long as equation [V(S)=V(A)H-WS]modulo SNS holds. If the transmitter is the 
mobile station and the pre-emptive transmission bit is set to 'O'in the PACKET UPLINK ACK/NACK message the 
transmitter shall not transmit the oldest RLC data block whose corresponding element in V(B) has the value 
PENDING_ACK (and the next continuing indefinitely). When a PACKET UPLINK ACK/NACK message is received 
the mobile station shall retransmit the RLC blocks which are set to NACKED in V(B) and new RLC data blocks as far 
as the transmit window (if advanced) allows. However if the RLC data block is the last in the TBF it shall be 
retransmitted even if its state is PENDING_ACK. The default for the mobile side is that the transmitter shall use pre- 
emptive transmission. If the transmitter is on the network side this process (pre-emptive transmission) of transmitting 
the oldest RLC data blocks whose value in V(B) has the value PENDING_ACK is optional. 
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NOTE: If the Mobile Station only has RLC data blocks whose value in V(B) has the value PENDING_ACK and 
the pre-emptive transmission bit is set to '0', the rules defined in sub-clause 8.1.1 apply (i.e. PACKET 
UPLINK DUMMY CONTROL BLOCK messages are sent). 

When an element in V(B) falls outside of the active transmit window, i.e. [ V(A) < BSN < V(S) ] modulo SNS, the 
element shall be set to the value INVALID. 

In the extended uphnk TBF mode, if V(S) = V(A) and there is no RLC data block with BSN = V(S) available, the 
mobile station shall stop sending RLC data blocks. The mobile station shall continue sending RLC data blocks when a 
RLC data block with BSN = V(S) is available. 

9.1 .3.3 Acknowledge State Array V(B) for non-persistent RLC mode 

In RLC non-persistent mode, the RLC endpoint transmitter shall have an associated acknowledge state array (V(B)). 
V(B) is an array of SNS elements indicating the acknowledgement status of WS previous RLC data blocks. The array is 
indexed relative to the acknowledge state variable V(A) modulo SNS. 

The values of V(B) shall be updated from the values received from its peers in the reported bitmap (RB) of the MBMS 
DOWNLINK ACK/NACK message (see sub-clause 9.1.8). If a compressed reported bitmap is received, decompression 
shall be first applied according to sub-clause 9.1.10. 

The transmitter may retransmit any RLC data block included in V(B), e.g. those whose corresponding element in V(B) 
indexed relative to V(A) have the value NACKED. As each RLC data block is transmitted the corresponding element in 
V(B) is set to the value PENDING_ACK. If an NPM Transfer Time limitation is associated with the MBMS bearer, the 
transmitting RLC endpoint shall start a timer with a value equal to the NPM Transfer Time (see Table 12.45a. 1) each 
time it begins transmitting a new upper layer PDU. If the timer expires, the transmitting RLC endpoint should not 
(re)transmit any of the RLC data blocks corresponding to that upper layer PDU, to avoid wasting radio resources. 

For an MBMS bearer running in EGPRS TBF mode, if the RLC data block intended for retransmission is split over two 
radio blocks, both radio blocks shall be transmitted. The selection of the Puncturing Scheme (PS) shall be performed 
according to sub-clause 9.3.2.1. 

9.1 .4 Block sequence number BSN 

9.1 .4.1 Block sequence number BSN for GPRS TBF 

Each RLC data block contains a block sequence number (BSN) field that is 7 bits in length. At the time that an 
in-sequence RLC data block is designated for transmission, the value of BSN is set equal to the value of the send state 
variable V(S). 

9.1 .4.2 Block sequence number BSN for EGPRS TBF 

Each RLC data block contains a block sequence number (BSN) field that is 1 1 bits in length. At the time that an 
in-sequence RLC data block is designated for transmission, the value of BSN is set equal to the value of the send state 
variable V(S). 

9.1 .4a Reduced Block Sequence Number RBSN 

Each downlink RLC/MAC control block contains a Reduced Block Sequence Number (RBSN) bit. At the time that an 
in-sequence RLC/MAC control block is designated for transmission, the value of RBSN is set equal to the value of the 
control send state variable V(CS), except when extended RLC/MAC control message segmentation is used, in which 
case the value of RBSN is set equal to '0' for the first RLC/MAC control block, and to '1' for the second RLC/MAC 
control block onwards. 

9.1 .4b Reduced Block Sequence Number extension RBSNe 

When extended RLC/MAC control message segmentation is used, the second to the ninth RLC/MAC control blocks 
shall contain a Reduced Block Sequence Number extension (RBSNe) field. The first RLC/MAC control block shall not 
contain a RBSNe field (see sub-clause 10.4.12b). At the time that an in-sequence RLC/MAC control block is designated 
for transmission, the value of RBSNe is set equal to the value of the control send state variable V(CS) minus 1 . 
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9.1 .5 Receive state variable V(R) 



Each RLC endpoint receiver shall have an associated receive state variable V(R). The receive state variable denotes the 
BSN which has a value one higher than the highest BSN yet received (modulo SNS). V(R) shall be set to the value '0' at 
the beginning of each TBF in which the RLC endpoint is the receiver. V(R) can take on the value through SNS - 1. 

In RLC acknowledged mode, V(R) shall be set to [ BSN' + 1 ] modulo SNS, where BSN' is the BSN of most recently 
received RLC data block, provided [ V(R) < BSN' < V(Q) + WS ] modulo SNS. 

In RLC unacknowledged mode, V(R) shall be set to [ BSN' + 1 ] modulo SNS, where BSN' is the BSN of most recently 
received RLC data block. 

In RLC non-persistent mode, V(R) of each receiving RLC endpoint shall be set to [ BSN' + 1 ] modulo SNS, where 
BSN' is the BSN of most recently received RLC data block, provided [ V(R) < BSN' < V(R) + SNS - WS ] 
modulo SNS. 

9.1 .6 Receive window state variable V(Q) 

Each RLC endpoint receiver shall have an associated receive window state variable V(Q). The receive window state 
variable denotes the lowest BSN not yet received (modulo SNS), therefore representing the start of the receive window. 
V(Q) shall be set to the value at the beginning of each TBF in which the RLC endpoint is the receiver. The receive 
window state variable can take on the value through SNS -1. 

In RLC acknowledged mode, the value of V(Q) shall be updated when the RLC receiver receives the RLC data block 
whose BSN is equal to V(Q). The value of V(Q) shall then be set to the BSN value of the next RLC data block in the 
receive window (modulo SNS) that has not yet been received, or it shall be set to V(R) if all RLC data blocks in the 
receive window have been received. 

In RLC unacknowledged mode, if [V(R) - V(Q)] modulo SNS > WS after updating V(R), then V(Q) is set to 
[V(R) - WS] modulo SNS. 

In RLC non-persistent mode, V(Q) of each receiving RLC endpoint shall be set to V(R) if all RLC data blocks in the 
receive window have been received or to BSN', where BSN' is the BSN value of the oldest RLC data block not yet 
received which: 

- meets the condition [V(R) - BSN'] modulo SNS < WS and 

it is still expected by the receiving RLC endpoint. If an NPM Transfer Time limitation is associated with the 
corresponding MBMS bearer, the receiving RLC endpoint shall start a timer with a value equal to the NPM 
Transfer Time (see Table 12. 45a. 1) for each RLC data block which is detected as missing (i.e. when an out-of- 
sequence condition is detected). When the timer expires the receiving RLC endpoint shall consider the missing 
RLC data block as no longer expected. If no NPM Transfer Time limitation is associated with the corresponding 
MBMS bearer, all the RLC data blocks not yet received, and meeting the condition in the bullet above, are still 
expected by the receiving RLC endpoint 

9.1 .7 Receive state array V(N) 

9.1 .7.1 Receive state array V(N) in GPRS TBF 

Each RLC endpoint receiver shall have an associated receive state array V(N). V(N) is an array of SNS elements 
indicating the receive status of WS previous RLC data blocks. The array is indexed relative to the receive state variable 
V(R) modulo SNS. When an RLC data block is received with BSN within the receive window, V(R) is treated 
according to sub-clause 9.1.5 and the element in V(N) corresponding to the received RLC data block is set to the value 
RECEIVED. 

An element in V(N), corresponding to a BSN such that [ V(R) < BSN < V(R) - WS ] modulo SNS, shall be set to the 
value INVALID. 
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9.1 .7.2 Receive state array V(N) in EGPRS TBF 

Each RLC endpoint receiver shall have an associated receive state array V(N). V(N) is an array of SNS elements 
indicating the receive status of WS RLC data blocks that are supposed to follow the block BSN=V(Q)-1. The array is 
indexed relative to the receive window state variable V(Q) modulo SNS. When an RLC data block is received with 
BSN within the receive window, the corresponding element in V(N) is set to the value RECEIVED. 

If the RLC data block is split over two radio blocks, the element shall be set to the value RECEIVED if and only if both 
radio blocks have been received. 

The elements in V(N) are set to the value INVALID at the beginning of each TBF. During the TBF, an element in V(N) 
that falls outside the receive window, shall be set to the value INVALID. 

9.1 .8 Starting sequence number (SSN) and received block bitmap (RBB) 

9.1 .8.1 Starting sequence number (SSN) and received block bitmap (RBB) in GPRS 

TBF 

The Packet Ack/Nack message contains a starting sequence number (SSN) and a received block bitmap (RBB). The 
Packet Ack/Nack message is sent by the RLC receiver and is received by the RLC transmitter. The SSN and RBB are 
determined as defined in this sub-clause and transmitted in RLC acknowledged, RLC unacknowledged and RLC non- 
persistent modes. The SSN and RBB may be ignored by the RLC transmitter in unacknowledged mode. 

The RBB is defined as a binary valued array of WS elements, where the index of each element takes value 0, 1,2, ..., 
WS-1 in the given order, respectively. The BSN values specified in the RBB are interpreted by subtracting the bit 
position in the bitmap from the starting sequence number (SSN) modulo SNS. 

A vahd BSN value in the RBB is one that is in the range [ V(A) < BSN < V(S) ] modulo SNS. 

These inequalities shall be interpreted in the following way: 

BSN is vahd if, and only if, [ BSN - V(A) ] modulo SNS < [ V(S) - V(A) ] modulo SNS. 

At the RLC transmitter: 

For each bit in the RBB whose corresponding BSN value is within the transmit window, if the bit contains the 
value '1', the corresponding element in V(B) indexed relative to SSN shall be set to the value ACKED. If the bit 
contains the value '0', the element in V(B) shall be set to the value NACKED. A bit within the RBB whose 
corresponding BSN is not within the transmit window, shall be ignored. If the RLC transmitter is on the mobile 
station side, the bit contains the value '0' and the number of block periods between the end of the block period 
used for the last transmission of the corresponding RLC data block and the beginning of the block period 
containing the Packet Uplink Ack/Nack message is less than (max(BS_CV_MAX,l) - 1) (i.e. the RLC data 
block was recently (re)transmitted and thus can not be validly negatively acknowledged in this particular Packet 
UpUnk Ack/Nack message), the element in V(B) shall not be modified. 

At the RLC receiver: 

The starting sequence number (SSN) is assigned the value of the receive state variable V(R). The received block 
bitmap (RBB) is assigned the WS elements whose indices, with incrementing order, correspond to elements in 
the receive state array V(N) at the receiver whose indices, with decrementing order, range backwards from 
[ V(R) - 1 ] to [ V(R) - WS ] (modulo SNS). For each bit in the bitmap, the bit is assigned the value T if the 
corresponding element in V(N) indexed relative to SSN has the value RECEIVED. The bit is assigned the value 
'0' if the element in V(N) has the value INVALID. 

When polled within a downlink RLC data block, the mobile station shall acknowledge all the RLC data blocks 
for this RLC instance that have been correctly received up to and including the radio block where the mobile 
station is polled. 

As an implementation option, the mobile station may also acknowledge as many as possible of the RLC data 
blocks that are correctly received after the radio block where the mobile station is polled. 
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9.1 .8.2 Starting sequence number (SSN) and received block bitmap (RBB) in 

EGPRSTBF 

The EGPRS Packet Ack/Nack message and MBMS DOWNLINK ACK/NACK message contains a starting sequence 
number (SSN) and a reported bitmap (RB). The EGPRS Packet Ack/Nack message and MBMS DOWNLINK 
ACK/NACK message are sent by the RLC receiver and are received by the RLC transmitter. The SSN and RB are 
determined as defined in this sub-clause and transmitted in RLC acknowledged, RLC unacknowledged and RLC non- 
persistent modes (note the SSN is calculated differently in EGPRS (refer to table 9.1.8.2.2.1) and GPRS (refer to sub- 
clause 9. 1 .8.1)). The SSN and RB may be ignored by the RLC transmitter in unacknowledged mode. 

The BSN values specified in the RB are interpreted by adding the bit position in the bitmap to the starting sequence 
number (SSN) modulo SNS (where the first position of the bitmap has index '0'). A valid BSN value in the RB is one 
that is in the range [ V(A) < BSN < V(S) ] modulo SNS. These inequalities shall be interpreted in the following way: 
BSN is vaUd if, and only if, [BSN - V(A) ] modulo SNS < [ V(S) - V(A) ] modulo SNS. 

9.1.8.2.1 Extended Polling 

For EGPRS uplink TBFs, the network may select any composition of the Packet Ack/Nack message to send to the 
mobile station. In EGPRS downlink TBFs and MBMS bearers running in EGPRS TBF mode, an additional poll bit is 
added to the S/P field in every downlink RLC block so that the network can request the following: 

- First Partial Bitmap (FPB) segment with SSN = (V(Q) + 1) mod SNS (the beginning of the window is V(Q) but 
FPB starts at V(Q) H- 1 as the bit in the bitmap corresponding to V(Q) would have value '0') where SSN denotes 
the Starting Sequence Number. 

- Next Partial Bitmap (NPB) segment with SSN = (PBSN + 1) mod SNS where PBSN denotes a Partial Bitmap 
Sequence Number variable stored at the receiver. 

SSN is determined by the receiver as a function of ES/P, V(Q) and PBSN as described in the next sub-clause. The FPB 
and NPB are specific instances of the EGPRS Ack/Nack Description Information Element within the EGPRS PACKET 
DOWNLINK ACK/NACK message or MBMS DOWNLINK ACK/NACK message. The mobile station shall respond 
to ES/P field according to table 9.1.8.2.1.1 (non-MBMS) or table 9.1.8.2.1.2 (MBMS). 

Table 9.1.8.2.1.1 : Format of ES/P field within each EGPRS RLC block (non-MBMS) 



ES/P 


Feedback Request (Poll) Description 


00 


Nothing (RRBP field invalid) 


01 


EGPRS PACKET DOWNLINK ACK/NACK message containing FPB (First Partial Bitmap), and 
if there is enough room left in RLC/IVIAC block, channel quality report 


10 


EGPRS PACKET DOWNLINK ACK/NACK message containing NPB (Next Partial Bitmap), 
and if there is enough room left in RLC/IVIAC block, channel quality report 


11 


EGPRS PACKET DOWNLINK ACK/NACK message containing Channel Quality Report and if 
there is enough room left in RLC/IVIAC block, NPB 



Table 9.1.8.2.1.2: Format of ES/P field within each EGPRS RLC block (MBMS) 



ES/P 


Feedback Request (Poll) Description 


00 


Nothing (RRBP field invalid) 


01 


IVIBMS DOWNLINK ACK/NACK message containing FPB (First Partial Bitmap) 


10 


IVIBMS DOWNLINK ACK/NACK message containing NPB (Next Partial Bitmap) 


11 


MBMS DOWNLINK ACK/NACK message containing neighbour cell measurement reports and 
NPB 



For MBMS bearers, in case cell re-selection criteria are not fulfilled (see 3GPP TS 45.008): 

If the ES/P field is set to '11' the mobile station shall include measurement reports for at least three neighbouring 
cells in addition to the NPB. If the complete NPB is included, the mobile station shall include measurement 
results for more neighbouring cells, if there is sufficient space; 

Else (i.e. the ES/P field is set to '01' or '10') the mobile station shall send as much of either the FPB or NPB (as 
specified in Table 9.1.8.2.1.2) as possible and, if the entire FPB/NPB is sent, measurement reports for as many 
neighbouring cells as can also be included. 
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For MBMS bearers, in case cell re-selection criteria are fulfilled towards a neighbouring cell (see 3GPP TS 45.008), the 
mobile station if polled shall include in the MBMS DOWNLINK ACK/N ACK message the measurement report only 
for that cell and as much of either the First Partial Bitmap (FPB) or Next Partial Bitmap (NPB) (as specified in Table 
9.1.8.2.1.2) as possible. 



9.1.8.2.2 



Determination of SSN 



If the receiving side is the network, the network may select any SSN within the receive window. If the receiving side is 
the mobile station, SSN shall be determined as follows: Let PBSN represent a Partial Bitmap Sequence Number 
variable stored at the receiver which helps to determine the Starting Sequence Number (SSN) for the next partial bitmap 
to be transmitted. Based on PBSN, V(Q) and the ES/P field set by the network, SSN and PBSN shall be determined 
according to table 9.1.8.2.2.1. 

Table 9.1.8.2.2.1 : Determination of SSN as a function of ES/P, V(Q) and PBSN 



Full bitmap 
(compressed or not) 


ES/P 


Determination of SSN 


- 


00 


- 


fits in available space 


01, 
10, 

11 


Set SSN = {V(Q)+^) modulo SNS 
set PBSN = V(Q). 


does not fit in available 
space 


01 


Set SSN = (V(Q)+^) modulo SNS, 

set PBSN = last sequence number for which Ack/Nack status can be indicated 
in available space in EGPRS PACKET DOWNLINK ACK/NACK or MBMS 
DOWNLINK ACK/NACK message. 


10, 

11 


If (PBSN+1)modulo SNS =V(Q) or (PBSN+1) modulo SNS lies outside the 

receiver windowset SSN = {V(Q)+'{) modulo SNS, 

else 

set SSN = (PBSN+1) modulo SNS and 

set PBSN = last sequence number for which Ack/Nack status can be indicated 

in available space in EGPRS PACKET DOWNLINK ACK/NACK or MBMS 

DOWNLINK ACK/NACK message. 



When a next partial bitmap needs to be transmitted in response to a poll, it may turn out that (Vf/Jj-PBSN) mod SNS is 
much smaller than the available space. In such cases, a larger amount of feedback can be provided as an implementation 
option if the receiver backtracks from PBSN and represents as much of the V(Q) to PBSN range as possible, in addition 
to the PBSN to V(R) range, possibly using compression. If backtracking is carried out, the SSN must be properly 
indicated within the Ack/Nack description in order to allow the transmitter to accurately interpret the feedback. For 
MBMS Bearers, this option may only apply if the cell re-selection criteria are fulfilled (see 3GPP TS 45.008). 



9.1.8.2.3 



Generation of the bitmap 



First, a Full Received Bitmap (FRB) is built from the receive state array V(N) by extracting the part between V(Q) and 
V(R) similar to the GPRS case: it is assigned the elements whose indices in the receive state array V(N) at the receiver 
range from [V(Q)h- 1] to [V(R) -1] (modulo SNS). For each bit in the bitmap, the bit is assigned the value '1' if the 
corresponding element in V(N) indexed relative to SSN has the value RECEIVED. The bit is assigned the value '0' if 
the element in V(N) has the value INVALID. 

From the FRB, a reported bitmap (RB) shall then be generated. The FRB shall be recalculated before each RB is 
generated. Different lengths of RBs exist (see clause 12). For uplink TBFs, the network may transmit any RB size to the 
mobile station. For downlink TBFs, the network may order the mobile station to transmit a certain RB size through use 
of the ES/P field. The bitmap size may be selected based on e.g. risk of protocol stalling. The RB is one of the following 
types: 

a) Uncompressed reported bitmap: 

If the range of indices from SSN to the end of FRB is less than or equal to N bits, where N is the reported 
bitmap size, the RB starts at SSN and covers the range of indices from SSN to the end of FRB. If the range of 
indices from SSN to the end of FRB is greater than N bits, the RB is assigned the first N bits of the FRB 
starting at SSN. 

b) Compressed reported bitmap: 
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Using the compression algorithm, the receiver generates RB of length N bits starting at SSN, where N is the 
reported bitmap size used. 

If the compressed reported bitmap covers more blocks than the uncompressed reported bitmap, the receiver shall send 
the compressed reported bitmap, otherwise the receiver shall send the uncompressed reported bitmap. As an exception, 
if the FRB length or the range of indices from SSN to the end of FRB is less than or equal to N bits, the receiver may 
send the uncompressed reported bitmap without attempting compression. 

The BOW (begin of window) bit shall be set if SSN = [V(Q) + 1] modulo SNS, the EOW (end of window) bit shall be 
set if [V(R) -1] modulo SNS is explicitly included in the bitmap. 

If V(Q) equals V(R), then SSN shall be set to the value SSN = [V(Q) + 1] modulo SNS, BOW bit shall be set to the 
value '1', EOW shall be set to the value '1' and the reported bitmap size shall equal bits. 

For uplink TBFs, the reported bitmap is sent using the PACKET UPLINK ACK/NACK message corresponding to the 
used RB size. 

For downlink TBFs or MBMS Bearers, the reported bitmap is sent using the EGPRS 

PACKET DOWNLINK ACK/NACK message or MBMS DOWNLINK ACK/NACK message respectively. 

9.1 .8.2.4 Interpretation of the bitmap 

If a compressed reported bitmap is received, the bitmap shall first be decompressed according to sub-clause 9.1.10. The 
uncompressed bitmap shall then be treated as follows: 

Firstly, if the BOW bit in PACKET UPLINK ACK/NACK or EGPRS PACKET DOWNLINK ACK/NACK message 
has the value '1', then the bitmap acknowledges all blocks between V(A) and (SSN- 2) (modulo SNS), and the 
corresponding elements in V(B) shall be set to the value ACKED. Also a bitmap value of '0' is assumed at the bit 
position corresponding to (SSN-1) modulo SNS which corresponds to V(Q). If the BOW bit in MBMS DOWNLINK 
ACK/NACK message has the value '1', then the bitmap acknowledges all blocks between V(A) and (SSN-2) (modulo 
SNS), and a bitmap value of '0' is assumed at the bit position corresponding to (SSN-1) modulo SNS, only for the 
mobile station sending the message. The decision whether to set the corresponding elements in V(B) to the value 
ACKED is implementation specific. 

Then, in case of PACKET UPLINK ACK/NACK or EGPRS PACKET DOWNLINK ACK/NACK message, for each 
bit in the uncompressed bitmap whose corresponding BSN value is within the transmit window, if the bit contains the 
value '1', the corresponding element in V(B) indexed relative to SSN shall be set to the value ACKED. If the bit 
contains the value '0', the element in V(B) shall be set to the value NACKED. A bit within the uncompressed bitmap 
whose corresponding BSN is not within the transmit window, shall be ignored. In case of MBMS DOWNLINK 
ACK/NACK message, for each bit in the uncompressed bitmap whose corresponding BSN value is within the transmit 
window, if the bit contains the value '1', it positively acknowledges the corresponding RLC data block only for the 
mobile station sending the message, and the decision whether to set to the value ACKED the corresponding element in 
V(B) indexed relative to SSN is implementation specific. If the bit contains the value '0', it negatively acknowledges the 
corresponding RLC data block only for the mobile station sending the message, and the decision whether to set to the 
value NACKED the corresponding element in V(B) indexed relative to SSN is implementation specific. A bit within the 
uncompressed bitmap whose corresponding BSN is not within the transmit window shall be ignored. 
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If the EOW bit in the PACKET UPLINK ACK/NACK,r EGPRS PACKET DOWNLINK ACK/NACK or MBMS 
DOWNLINK ACK/NACK message has the value '1', then bitmap value '0' shall be assumed for all RLC blocks with a 
BSN value higher than the last entry in the bitmap but less than V(S) (i.e. [ V(R) - 1 < BSN < V(S)] modulo SNS). If 
the RLC transmitter is on the mobile station side, the bit contains the value '0' and the number of block periods between 
the end of the block period used for the last transmission of the corresponding RLC data block and the beginning of the 
block period containing the PACKET UPLINK ACK/NACK message is less than (max(BS_CV_MAX,l) - 1) (i.e. the 
RLC data block was recently (re)transmitted and thus can not be validly negatively acknowledged in this particular 
PACKET UPLINK ACK/NACK message), the element in V(B) shall not be modified. Similarly, if the RLC transmitter 
is on the network side and the RLC data block cannot be validly negatively acknowledged in this particular EGPRS 
PACKET DOWNLINK ACK/NACK message or MBMS DOWNLINK ACK/NACK message the element in V(B) 
shall not be modified. 

9.1.9 Window Size 

9.1.9.1 GPRS 

For GPRS, the window size (WS) shall be 64. 

9.1.9.2 EGPRS 

A mobile station may support the use of the GPRS multislot class also for the EGPRS-GMSK only TBF mode. The 
support of this feature must be indicated as the "Modulation based multislot class support" information in the MS Radio 
Access Capability IE and the MS Radio Access Capability 2 IE. 

A mobile station in EGPRS TBF mode not supporting the "Modulation based multislot class support" shall apply the 
EGPRS multislot class. A mobile station in EGPRS-GMSK only TBF mode shall apply the GPRS multislot class. 

While a EGPRS-GMSK only TBF mode is in progress, if a mobile station receives DL blocks not coded with 
modulation and coding scheme MCS-1 to MCS-4 then the MS behavior is implementation specific. 

For EGPRS the window size ( WS) shall be set by the network according to the number of timeslots allocated in the 
direction of the TBF (uplink or downlink) using the applicable multislot capability. The allowed window sizes are given 
in table 9.L9.2. L Preferably, the selected window size should be the maximum, or follow the definition in annex I. 

The window size may be set independently for each TBF on uplink and downlink. The mobile station shall support the 
maximum window size corresponding to its multislot capability. The selected WS shall be indicated within a PACKET 
UL/DL ASSIGNMENT, MULTIPLE TBF UL/DL ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, 
MULTIPLE TBF TIMESLOT RECONFIGURE or PACKET CS RELEASE INDICATION message using the coding 
defined in table 9.1.9.2.1. 

Once a window size is selected for a given TBF, it may be changed to a larger size but not to a smaller size, in order to 
prevent dropping data blocks from the window. 

In case the MS multislot class is not indicated during packet data connection establishment (access request for 
signalling message transfer), a default window size corresponding to the minimum window size for 1 timeslot (as 
defined in table 9.1.9.2.1) shall be selected. 

In case a PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE message is sent 
to the mobile station without any window size for a specific TBF, then any previous value received for the specific TBF 
shall be used or, if no previous value has been received for the specific TBF, default window size shall be used. 

NOTE: If a TBF is reallocated so that the number of allocated timeslots is reduced, the RLC window size may 
become larger than the maximum window size for the new resources. 
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Table 9.1.9.2.1 : Allowed window sizes in EGPRS TBF mode for different multislot allocations 



Window 
size 


Coding 


Timeslots allocated (multislot capability) 


1 


2 


3 


4 


5 


6 


7 


8 


64 


00000 


















96 


00001 


















128 


00010 


















160 


00011 


















192 


00100 


Max 
















224 


00101 


















256 


00110 




Max 














288 


00111 


















320 


01000 


















352 


01001 


















384 


01010 






Max 












416 


01011 


















448 


01100 


















480 


01101 


















512 


01110 








Max 










544 


01111 


















576 


10000 


















608 


10001 


















640 


10010 










Max 








672 


10011 


















704 


10100 


















736 


10101 


















768 


10110 












Max 






800 


10111 


















832 


11000 


















864 


11001 


















896 


11010 














Max 




928 


11011 


















960 


11100 


















992 


11101 


















1024 


11110 
















Max 


Reserved 


11111 


X 


X 


X 


X 


X 


X 


X 


X 


NOTE: The shaded cells represent the allowed window sizes. 



9.1.9.3 



RLC buffer 



A mobile station supporting multiple TBF shall support one RLC buffer per direction (uplink and downlink). The RLC 
buffer in a given direction represents the amount of physical memory the mobile station shall support in this direction 
for RLC PDUs from all RLC instances in the transmit (uplink) or receive (downlink) window(s). The RLC buffer size is 
given as the maximum number of RLC data blocks that can be stored in this buffer assuming the highest (modulation 
and) coding scheme supported by the mobile station in this direction. The RLC buffer shall be as follows: 

A mobile station supporting GPRS (not supporting EGPRS) shall support a RLC buffer of size 64 in both uplink 
and downlink directions 

A mobile station supporting EGPRS shall support RLC buffers as defined in the table below 
Table 9.1.9.3: RLC buffer in a given direction for EGPRS capable MS 





Maximum amount Wot timeslots the MS supports in this direction (see note 1) 




1 


2 


3 


4 


5 


6 


7 


8 


RLC buffer size S 
(see note 2) 


192 


256 


384 


512 


640 


768 


896 


1024 


NOTE 1 : See 3GPP TS 45.002 for multislot classes 

NOTE 2: An EGPRS capable mobile station able to support up to A/ timeslots in a direction shall support an RLC buffer in 
this direction that can store S RLC data blocks 
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NOTE: The sum of the RLC window sizes of all RLC instances running in the mobile station in a given direction 
may be larger than the mobile station's RLC buffer in this direction. The RLC buffer does not affect the 
allocation of RLC window size. 

9.1.10 Compression 

The compression algorithm is as follows. If the window size is less than the number of bits available for the bitmap, 
then full feedback is provided using an uncompressed bitmap. If the window size is larger than the number of bits 
available for the bitmap, then one-dimensional run length coding (based on ITU-T Recommendation T.4) is carried out 
starting at SSN. 

The T.4 procedure for encoding run lengths is as follows. Runs of ones and zeros alternate, and the run lengths are 
represented by the code words listed in the tables below. The code words for run lengths of zeros and ones are as 
described in T.4 except for one minor modification: the terminating code words used for indicating run lengths of 1 zero 
and 3 zeros are interchanged. This modification helps in achieving some throughput improvement when frequency 
hopping is carried out. The run length code words are of two types: terminating code words and make-up code words. 
Each run length is represented by either one terminating code word or one make-up code word followed by a 
terminating code word. Run lengths in the range 0-63 bits are encoded with their appropriate terminating code word. 
Run lengths greater than 63 bits are encoded first by the make-up code word which is equal to or shorter than that 
required. This is then followed by the terminating code word representing the difference between the required run 
length and the run length represented by the make-up code. 

No special code words are used either at the beginning of the bitmap or the end of a bitmap. A one bit indicator 
(i.e. Compressed Bitmap Starting Color Code) is used to indicate whether the compressed bitmap starts with a run 
length of zeros or a run length of ones. 

The compressed bitmap is assumed to be of length Lc (see clause 12) bits. The run length encoder output is used only if 
a compression gain is realized; otherwise an uncompressed partial bitmap is transmitted. The compressed portion of the 
bitmap must end on a T.4 code word boundary which may or may not coincide with the number of bits available. In 
such cases, one possible implementation is to recognize the boundary of the last valid T.4 code word that fits into the 
available space as the end of the compressed bitmap. The rest of the bitmap is assumed to be uncompressed; the 
uncompressed portion of the bitmap has variable length (see clause 12). Any bits representing sequence numbers V(R) 
or beyond in either the compressed or uncompressed portion of the bitmap must be set to 0. Implementations may use 
other schemes to determine the boundary between the compressed and uncompressed portions of the bitmap. 

Table 9.1.10.1 : Terminating codes (reproduced from ITU-T Recommendation T.4); 
T.4 code words used for representing run lengths of 1 zero and 3 zeros are interchanged 

r One run length | Code word | Zero run length | Code word | 
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One run length 


Code word 


Zero run length 


Code word 





00110101 





0000110111 


1 


000111 


1 


10 


2 


0111 


2 


11 


3 


1000 


3 


010 


4 


1011 


4 


oil 


5 


1100 


5 


0011 


6 


1110 


6 


0010 


7 


1111 


7 


00011 


8 


10011 


8 


000101 


9 


10100 


9 


000100 


10 


00111 


10 


0000100 


11 


01000 


11 


0000101 


12 


001000 


12 


0000111 


13 


000011 


13 


00000100 


14 


110100 


14 


000001 1 1 


15 


110101 


15 


000011000 


16 


101010 


16 


0000010111 


17 


101011 


17 


000001 1 000 


18 


0100111 


18 


0000001000 


19 


0001100 


19 


00001100111 


20 


0001000 


20 


00001101000 


21 


0010111 


21 


00001101100 


22 


0000011 


22 


00000110111 


23 


0000100 


23 


00000101000 


24 


0101000 


24 


00000010111 


25 


0101011 


25 


00000011000 


26 


0010011 


26 


000011001010 


27 


0100100 


27 


000011001011 


28 


0011000 


28 


000011001100 


29 


00000010 


29 


000011001101 


30 


00000011 


30 


000001101000 


31 


00011010 


31 


000001101001 


32 


00011011 


32 


000001101010 


33 


00010010 


33 


000001101011 


34 


00010011 


34 


000011010010 


35 


00010100 


35 


000011010011 


36 


00010101 


36 


000011010100 


37 


00010110 


37 


000011010101 


38 


00010111 


38 


000011010110 


39 


00101000 


39 


000011010111 


40 


00101001 


40 


000001101100 


41 


00101010 


41 


000001101101 


42 


00101011 


42 


000011011010 


43 


00101100 


43 


000011011011 


44 


00101101 


44 


000001010100 


45 


00000100 


45 


000001010101 


46 


00000101 


46 


000001010110 


47 


00001010 


47 


000001010111 


48 


00001011 


48 


000001100100 


49 


01010010 


49 


000001100101 


50 


01010011 


50 


000001010010 


51 


01010100 


51 


000001010011 


52 


01010101 


52 


000000100100 


53 


00100100 


53 


000000110111 


54 


00100101 


54 


000000111000 


55 


01011000 


55 


000000100111 


56 


01011001 


56 


000000101000 


57 


01011010 


57 


000001011000 


58 


01011011 


58 


000001011001 


59 


01001010 


59 


000000101011 


60 


01001011 


60 


000000101100 


61 


00110010 


61 


000001011010 


62 


00110011 


62 


000001100110 
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One run length 


Code word 


Zero run length 


Code word 


63 


00110100 


63 


000001100111 



Table 9.1.10.2: Make-up codes 
(reproduced from ITU-T Recommendation T.4) 



One run length 


Code word 


Zero run length 


Code word 


64 


11011 


64 


0000001 1 1 1 


128 


10010 


128 


000011001000 


192 


010111 


192 


000011001001 


256 


0110111 


256 


000001011011 


320 


00110110 


320 


000000110011 


384 


00110111 


384 


000000110100 


448 


01100100 


448 


000000110101 


512 


01100101 


512 


0000001101100 


576 


01101000 


576 


0000001101101 


640 


01100111 


640 


0000001001010 


704 


011001100 


704 


0000001001011 


768 


011001101 


768 


0000001001100 


832 


011010010 


832 


0000001001101 


896 


011010011 


896 


0000001110010 


960 


011010100 


960 


0000001110011 



9.1 .11 Segmentation of upper layer PDUs into RLC (data units 

Segmentation of upper layer PDUs is supported to allow transport of upper layer PDUs larger than the data field of a 
single RLC data block. If the contents of an upper layer PDU do not fill an integer number of RLC data blocks, the 
beginning of the next upper layer PDU shall be placed within the final RLC data block of the first upper layer PDU, 
with no padding or spacing between the end of the first upper layer PDU and the beginning of the next. If the final 
upper layer PDU in the TBF does not fill an integer number of RLC data blocks, filler octets shall be used to fill the 
remainder of the RLC data block. 

The received (and segmented) upper layer PDUs shall be put into RLC data blocks in the same order as they are 
received from higher layers, except if resource reallocation for an uplink TBF is needed as described in sub-clause 
8.LLL2. A Block Sequence Number (BSN) is included in the header of each RLC data block to number the RLC data 
block. The RLC data blocks are to be numbered consecutively, modulo SNS, to allow re-assembly of the upper layer 
PDUs on the receiving side. 

In GPRS TBF mode, once an RLC data block has been transmitted over the physical link, should it be necessary to re- 
transmit the RLC data block, it shall be re-transmitted using the same channel coding scheme, BSN, and CV as it had in 
the previous transmission. 

In EGPRS TBF mode, once an RLC data block has been transmitted over the physical link, should it be necessary to re- 
transmit the RLC data block, it shall be re-transmitted using the same BSN and the same calculated CV as were used in 
the previous transmission. The modulation and coding scheme may be changed following the procedures described in 
sub-clause 9.3.2.1. 

9.1 .12 Re-assembly of upper layer PDUs from RLC (data units 

RLC data blocks shall be collected at the receiver until all RLC data blocks comprising an upper layer PDU have been 
received. The RLC headers shall be removed from each RLC data block at this time and the RLC data units re- 
assembled into an upper layer PDU and passed to the next higher layer. In A/Gb mode, the size of the upper layer PDU 
delivered to the higher layer shall not exceed 1560 octets. Any octet received beyond this maximum limit and until the 
next identified upper layer PDU boundary shall be discarded. 

During RLC acknowledged mode operation, received upper layer PDUs shall be delivered to the higher layer in the 
order in which they were originally transmitted. 

During RLC unacknowledged mode operation, received upper layer PDUs shall be delivered to the higher layer in the 
order in which they are received. 
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During RLC non-persistent mode operation, received upper layer PDUs shall be delivered to the higher layer in the 
order in which they were originally transmitted. Nevertheless, since some RLC data units may not be received, some 
upper layer PDUs may be re-assembled and delivered to the higher layer erroneously. The receiving RLC endpoint shall 
use RLC data units up to the one characterized by BSN = V(Q) - 1 when reassembling upper layer PDUs, even if some 
RLC data units are missing. 

Fill bits having the value '0' shall be substituted for RLC data units not received. However, in EGPRS TBF mode, for 
erroneous RLC data blocks for which the header is correctly received, the output from decoder shall be delivered to the 
higher layer. The number of fill bits substituted shall be determined using Table 9.1.12. In the uplink direction the 
channel coding scheme shall be the commanded channel coding scheme. In the downlink direction the channel coding 
scheme shall be the channel coding scheme of the last correctly received RLC data block. If no RLC data blocks have 
been correctly received, by the mobile station the requested channel coding scheme shall be used. If no requested 
channel coding scheme has been sent to the network, the mobile station shall use the number of fill bits for CS-1. 

Table 9.1.12.a: RLC unacknowledged mode fill bits 



Channel Coding 
Scheme 


Number of fill 
bits 


CS-1 


160 


CS-2 


240 


CS-3 


288 


CS-4 


400 



Table 9. 1.1 2. b: RLC unacknowledged mode fill bits 



Channel Coding 
Scheme 


Number of fill 
bits 


MCS-1 


176 


MCS-2 


224 


MCS-3 


296 


MCS-4 


352 


MCS-5 


448 


MCS-6 


592 


MCS-7 


448 


MCS-8 


544 


MCS-9 


592 



9.1 .12a Segmentation of RLC/MAC control messages into RLC/MAC control 
blocks 

The network may segment RLC/MAC control messages into one, two or up to nine RLC/MAC control blocks 
depending on the length of the RLC/MAC control message. Segmentation of an RLC/MAC control message into more 
than two RLC/MAC control blocks is referred to as extended RLC/MAC control message segmentation. Extended 
RLC/MAC control message segmentation shall not be used for an RLC/MAC control message that can be sent using 
one or two RLC/MAC control blocks. Unless explicitly stated otherwise, extended RLC/MAC control message 
segmentation shall not be used. If the contents of a control message do not fit an integer number of control blocks, filler 
octets shall be used to fill the remainder of the RLC/MAC control block. Only the last RLC/MAC control block 
containing elements of the control message shall contain filler octets. The Final Segment (FS) bit of the RLC/MAC 
control block header shall be set according to whether the RLC/MAC control block contains the final segment of an 
RLC/MAC control message, except in case of extended RLC/MAC control message segmentation in which case the FS 
bit shall always be set to '0' . In case of extended RLC/MAC control message segmentation, the Final Segment 
extension (FSe) bit of the RLC/MAC control block header (included in the second RLC/MAC control block onwards) 
shall be set according to whether the RLC/MAC control block contains the final segment of an RLC/MAC control 
message (see sub-clauses 10.4. 9e and 10.4.12b). 

The mobile station shall not segment RLC/MAC control messages. 
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NOTE: In order to provide the mobile station a Power Reduction value in a RLC/MAC control block, the network 
may use the segmentation mechanism although the RLC/MAC control block requires only one 
RLC/MAC control block to be transmitted. In that case the RBSN shall be set to '0' and FS shall be set to 

'1'. 

9.1 .12b Re-assembly of RLC/MAC control messages from RLC/MAC control 
blocks 

RLC/MAC control blocks shall be collected at the receiver until all RLC/MAC control blocks comprising an 
RLC/MAC control message have been received. 

In packet idle mode, the mobile station shall be capable of receiving eight RLC/MAC control messages in parallel. If 
the mobile station receives RLC/MAC control blocks containing part of a ninth RLC/MAC control message while it 
still has RLC/MAC control blocks for eight partially received RLC/MAC control messages, the mobile station shall 
discard the RLC/MAC control blocks of the oldest partially received message. 

In packet transfer mode, the mobile station shall be capable of receiving two RLC/MAC control messages in parallel on 
the same PDCH. If the mobile station receives RLC/MAC control blocks containing part of a third RLC/MAC control 
message while it still has RLC/MAC control blocks for two partially received RLC/MAC control messages, the mobile 
station shall discard the RLC/MAC control block of the oldest partially received message. 

The mobile station shall start an instance of timer T3200 following the receipt of an RLC/MAC control block whose 
RTI value does not correspond to the RTI value of a partially received RLC/MAC control message or if the RLC/MAC 
control blocks were received on different PDCHs. In non-DRX mode the duration of timer T3200 shall be four 
BS_CV_MAX block periods. In DRX mode the duration of timer T3200 shall be four times the DRX period (see 
3GPP TS 43.064). 

On receipt of an RLC/MAC control block containing a segment of an RLC/MAC control message such that the mobile 
station still does not have the complete RLC/MAC control message, the mobile station shall restart the corresponding 
instance of timer T3200. 

On receipt of an RLC/MAC control block containing a segment of an RLC/MAC control message such that the mobile 
station now has the complete RLC/MAC control message, the mobile station shall stop the corresponding instance of 
timer T3200. 

If the mobile station discards a partially received RLC/MAC control message while the corresponding instance of timer 
T3200 is running, the mobile station shall stop the corresponding instance of timer T3200. 

On expiry of an instance of timer T3200, the mobile station shall discard and ignore all segments of the corresponding 
partially received RLC/MAC control message. 

Upon successful change of PDCH allocation, the mobile station shall discard all partially received RLC/MAC control 
messages and stop the corresponding instances of timer T3200. 

The mobile station shall discard any control message segment that contains an unknown TFI. 

9.1.13 Priority of upper layer PDUs 

The mobile station shall not transmit upper layer PDUs during a TBF that have a lower Radio Priority than the priority 
that was used at initial access or the priority sent in the last PACKET RESOURCE REQUEST message, except if the 
upper layer PDUs at the higher Radio Priority does not completely fill the RLC data block (see sub-clause 8.LLL2). 
The mobile station may change the Radio Priority of an uplink TBF by sending a PACKET RESOURCE REQUEST 

message to the network (see sub-clause 8.LLL2). 

9.2 Operation during RLC/MAC control message transfer 

RLC/MAC control blocks shall be used to transport RLC/MAC control messages. Segments of only one RLC/MAC 
control message shall be transported per RLC/MAC control block. 

RLC/MAC control blocks shall be sent at a higher priority than RLC data blocks. 
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The receiving side shall determine the length of the RLC/MAC control message contents by interpreting the RLC/MAC 
control block contents. 

No general acknowledgement shall be made as part of the transfer of RLC/MAC control blocks or RLC/MAC control 
messages. The receiver shall not acknowledge an RLC/MAC control block except when a valid RRBP field is present in 
the MAC header of the RLC/MAC control block. The receiver shall not acknowledge an RLC/MAC control message 
except when the RLC/MAC procedures explicitly specify an acknowledgement. 

Each downlink RLC/MAC control block header, if present, contains a Radio Transaction Identifier (RTI) field that is 5 
bits in length and performs in effect a modulo 32 count of the downlink RLC/MAC control messages sent on a PDCH. 
The RTI field shall be used to group the RLC/MAC control blocks that make up an RLC/MAC control message. The 
RTI field allows the transmitting and receiving entities to distinguish between up to 32 RLC/MAC control messages in 
a single transmit direction therefore allowing up to 32 parallel transactions per PDCH. 

The network shall not use the same RTI value at the same time on the same PDCH for two separate RLC/MAC control 
messages. The network may use the same RTI value at the same time on separate PDCHs. The network shall transmit 
all segments of a segmented control message on the same PDCH. 

9.3 Operation during RLC data block transfer 

9.3.0 General 

The RLC ARQ functions support three modes of operation: RLC acknowledged mode, RLC unacknowledged mode and 
RLC non-persistent mode. RLC acknowledged mode operation uses retransmission of RLC data blocks to achieve high 
reliability. RLC unacknowledged mode operation does not utilize retransmission of RLC data blocks. RLC non- 
persistent mode operation uses non-exhaustive retransmission of RLC data blocks. A TBF may operate in either RLC 
acknowledged mode or RLC unacknowledged mode. An MBMS bearer operates in RLC non-persistent mode. 

The mobile station requests the RLC mode of the uplink TBF by setting the RLC_MODE bit to either RLC 
acknowledged mode or RLC unacknowledged mode in the PACKET RESOURCE REQUEST or the (EGPRS) 
PACKET DOWNLINK ACK/NACK message. When the establishment cause field in the PACKET CHANNEL 
REQUEST message indicates 'one phase access', the RLC mode defaults to RLC acknowledged mode. If both the 
mobile station and the BSS support multiple TBF procedures, the BSS may override the mobile station's indicated RLC 
mode, ordering its preferred RLC mode when establishing uplink TBF(s) as follows: 

- The network shall always set the RLC_MODE bit for the uplink TBF(s) in the MULTIPLE TBF UPLINK 
ASSIGNMENT and MULTIPLE TBF TIMESLOT RECONFIGURE messages. 

- The network may order the RLC mode for the uplink TBF by setting the RLC_MODE bit in the PACKET 
UPLINK ASSIGNMENT message or the UPLINK_RLC_MODE bit in the PACKET TIMESLOT 
RECONFIGURE message. The mobile station shall assume that its indicated RLC mode is used if the BSS does 
not override it in the PACKET UPLINK ASSIGNMENT or PACKET TIMESLOT RECONFIGURE message. 

The network sets the RLC mode of the downlink TBF by setting the RLC_MODE bit in the PACKET DOWNLINK 
ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, 
MULTIPLE TBF TIMESLOT RECONFIGURE or PACKET CS RELEASE INDICATION message. 

An uplink TBF may be operating in either non-extended uplink TBF mode or extended uplink TBF mode, see sub- 
clause 9.3.1b. 

When one or more PDCH/Fs are used in conjunction with one PDCH/H in the same direction, the RLC/MAC data 
blocks may not be received in the same sequence they were sent, due to the different data rates of the channels. In RLC 
unacknowledged mode, the sending entity shall re-order the RLC/MAC data blocks before transmission to ensure their 
reception in sequence. 

9.3.1 Countdown procedure 
9.3.1.1 General 

The mobile station shall send the Countdown Value (CV) in each uplink RLC data block to indicate the current number 
of remaining RLC data blocks for the uplink TBF. The CV shall be calculated as follows: 
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, . Jtbc-bsn'-i 

Let integer x=round\ 

1^ NTS X K 

[x, ifx<BS CV MAX, 

then, Cy = ^ - - , 

[15, otherwise. 

where: 

TBC = total number of RLC data blocks currently to be transmitted in the TBF. 

BSN' = absolute block sequence number of the RLC data block, with range from to (TBC - 1). 

NTS = number of timeslots assigned to the uplink TBF in the assignment message, with range 1 to 8. 

K = 2 when commanded MCS is MCS-7, MCS-8 or MCS-9, otherwise K=l, 

the function round() rounds upwards to the nearest integer. 
BS_CV_MAX is a parameter broadcast in the system information, 

the division operation is non-integer and results in zero only for (TBC - BSN' - 1) = 0. 

The countdown procedure starts when RLC data blocks include CV values different from '15'. When the mobile station 
transmits the last RLC data block currently in the send buffer for the TBF (i.e. the RLC data block with BSN' = TBC - 
1), the RLC data block shall have CV set to the value '0'. 

When an EGPRS RLC/MAC block for data transfer consists of two RLC data blocks, a CV value is calculated for each 
block and the CV of the RLC/MAC header refers to the second RLC data block. 

9.3.1 .2 Non-extended uplink TBF mode 

In an uplink TBF operating in non-extended uplink TBF mode, the CV shall indicate the absolute BSN (BSN') of the 
last RLC data block that will be sent in the uplink TBF. The TBC value is the total number of RLC data blocks that will 
be transmitted in the TBF. 

At the point in time the mobile station having an uplink TBF in non-extended TBF mode transmits the first RLC data 
block indicating a CV other than 15, the mobile station shall transmit afterwards exactly (TBC - BSN' - 1) untransmitted 
RLC data blocks. 

If the mobile station receives a change in the Channel Coding Command in a PACKET UPLINK ACK/NACK message 
during the countdown procedure, the mobile station shall act upon the new Channel Coding Command. The mobile 
station shall then recalculate the CV for any untransmitted RLC data block using the new RLC data block size. 

If the mobile station successfully complete the contention resolution procedure during one phase access and the 
countdown procedure is already running,, the mobile station shall recalculate the CV for any untransmitted RLC data 
blocks. 

Any data that arrives from the higher layer after the commencement of the countdown process shall be sent within a 
future TBF. 

The mobile station may retransmit during the countdown in response to a Packet Ack/Nack or if stalled. 

If the mobile station receives a new allocation during the countdown, the mobile station shall use this new allocation to 
the end of the countdown procedure. The network shall provide unsolicited uplink resources for any retransmissions 
that may be required. 

9.3.1.3 Extended uplink TBF mode 

In an uplink TBF operating in extended uplink TBF mode, the CV shall indicate the current number of RLC data blocks 
that has not been transmitted in the uplink TBF. The mobile station shall update the TBC value and recalculate the CV 
for any untransmitted RLC data block in the following cases: 

The RLC entity of the mobile station receives new data from upper layers for transmission in the uplink TBF. 
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The mobile station completes the contention resolution at one-phase packet access. 

The mobile station changes the coding scheme of the RLC data blocks transmitted in an uplink TBF operating in 
GPRS TBF mode. 

The mobile station changes the modulation and coding scheme of the RLC data blocks transmitted in an uplink 
TBF operating in EGPRS TBF mode. 

NOTE: Updating the TBC value shall not result in changing the CV of the RLC data blocks already transmitted, 
in the case they need to be retransmitted. 

9.3.1a Delayed release of downlink Temporary Block Flow 

When the network exhausts its supply of downlink data for a downlink TBF, it may release the TBF by using one of the 
procedures in sub-clause 9.3.2.6 or sub-clause 9.3.3.5. If a TBF is not instantly released, the network may continue the 
downlink TBF awaiting new data to be received from the upper layers. After a period of inactivity, the TBF shall be 
released at a point determined by the network, using one of the procedures in sub-clause 9.3.2.6, sub-clause 9.3.3.5 or 
sub-clause 8. 1 .2.8. Once the release of a downlink TBF is initiated, the TBF shall not be continued. 

If the network continues a downlink TBF when the supply of downlink data is exhausted, the RLC entity on the 
network side shall insert filler information into the RLC data blocks that are transmitted to the mobile station. For a 
mobile station operating in A/Gb mode, this is achieved by the insertion of LLC UI Dummy commands (see 
3GPP TS 44.064) into the TBF. For a mobile station operating in lu mode, the network may directly transmit RLC data 
blocks with filler information by setting the LI field as described in sub-clauses 10.4.14 and 10.4.14a. The FBI bit in the 
RLC header shall be set to the value '0' unless the network releases the TBF, in which case the FBI bit shall be set to the 
value 1. 

If new data is received from the upper layers, the network stops sending filler information and resumes normal 
operation during RLC data block transfer. 

RLC data blocks shall be sent to the mobile station as required to prevent the expiry of timer T3 190 for each TBF, 
according to power control requirements, and as needed to poll the mobile station for the provision of PACCH uplink 
blocks. 

NOTE: Extensive delay of a downlink TBF release might impact badly on the mobile station power consumption 
and should be avoided. Inactivity periods should not be longer than necessary to keep the overall 
performance of GPRS services. Inactivity periods longer than 5 s should not be used. 

9.3.1 b Extended uplink TBF mode 
9.3.1 b.1 Application 

Network support of the extended uplink TBF mode shall be indicated by the NW_EXT_UTBF parameter that is 
broadcast on either BCCH or PBCCH, see sub-clause 12.24. 

The mobile station shall support the extended uplink TBF mode. The extended uplink TBF mode is a part of the 
GERAN Feature Package 1 . A mobile station indicating support of GERAN Feature Package 1 in the Mobile Station 
Classmark 3 IE, the MS Radio Access Capability IE and the MS Radio Access Capability 2 IE supports the extended 
upUnk TBF mode (see 3GPP TS 24.008). 

The RLC/MAC entity, which has received the indication that the peer supports the extended uplink TBF mode, shall 
operate an uplink TBF in the extended uplink TBF mode. 

NOTE: The network might not receive the radio access capabilities of the mobile station at one -phase packet 
access. In that case, the two entities may operate in different mode. 

9.3.1 b.2 Operation of uplink TBF In extended uplink TBF mode 

In extended uplink TBF mode, an uplink TBF may be maintained during temporary inactive periods, where the mobile 
station has no RLC information to send. 
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During the temporary inactive periods, the mobile station may stop sending RLC data block, as defined in sub- 
clause 9.1.3. The network shall continue allocating the mobile station uplink radio blocks during the inactivity period, 
using the procedures defined in sub-clause 8.1.1 for each medium access mode. Uplink radio blocks shall be allocated 
as required allowing the mobile station to continue the transfer of RLC data blocks, when a new RLC data block 
becomes available. 

When the mobile station is allocated an uplink radio block and there is no RLC data block ready to send for any TBF, 
the mobile station shall send an RLC/MAC control block in each uplink radio block allocated by the network, unless 
indicated otherwise. When the mobile station is allocated an uplink radio block, and there is no RLC/MAC block for 
data transfer to send for this TBF but, in case of multiple TBFs, there is an RLC/MAC block for data transfer to send for 
one or more other TBF(s) assigned on the same PDCH, the mobile station should send an RLC/MAC block for data 
transfer from one of these other TBF(s) in the allocated uplink radio block indicating the TFI of that other TBF in the 
RLC/MAC header of that RLC/MAC block. The priorities defined in sub-clause 8. 1 . 1 for different kinds of RLC/MAC 
blocks apply. The network may allow, via the EXT_UTBF_NODATA parameter broadcast in GPRS Cell Options IE 
(see sub-clause 12.24), any mobile station during extended uplink TBF mode not to send any PACKET UPLINK 
DUMMY CONTROL BLOCK message when there is no other RLC/MAC block ready to send. A mobile station during 
extended uplink TBF mode may refrain from sending PACKET UPLINK DUMMY CONTROL BLOCK messages 
when there is no other RLC/MAC block ready to send only if so indicated by the EXT_UTBF_NODATA parameter. 

During a period when the network does not receive any RLC data blocks from the mobile station, the network may 
periodically send a PACKET UPLINK ACK/NACK message to the mobile station. When applicable, depending on the 
medium access mode, the PACKET UPLINK ACK/NACK message shall be sent as required to prevent timer T3184 
from expiring. 

The network determines the release of an uplink TBF. The network releases an uplink TBF using the procedure in sub- 
clause 9.5 (A/Gb mode) or 3GPP TS 44.160). 

NOTE 1: An uplink TBF may be released also by procedures defined in clause 8. 

NOTE 2: Extensive delay of an uplink TBF release whilst the mobile station does not send any RLC information 
might impact badly on the mobile station power consumption and should be avoided. Inactivity periods 
should not be longer than necessary to keep the overall performance of GPRS services. Inactivity periods 
longer than 5 s should not be allowed. If, however, the network has indicated that the mobile station 
during extended uplink TBF mode is not required to send PACKET UPLINK DUMMY CONTROL 
BLOCK messages, as described above, and the mobile station makes use of this option, the impact on the 
mobile station power consumption will be less critical and longer inactivity periods than 5 seconds can be 
allowed. 

9.3.2 Acknowledged mode operation 

9.3.2.0 General 

The transfer of RLC data blocks in the RLC acknowledged mode uses retransmissions of RLC data blocks. The 
transmitting side numbers the RLC data blocks via the block sequence number (BSN). The BSN is used for 
retransmission and for reassembly. The receiving side sends PACKET Ack/Nack messages in order to request 
retransmission of RLC data blocks. 

9.3.2.1 Additional functionality in acknowledged EGPRS TBF Mode 

In EGPRS TBF mode, the transfer of RLC Data Blocks in the acknowledged RLC/MAC mode may be controlled by a 
selective type I ARQ mechanism, or by type II hybrid ARQ (Incremental Redundancy: IR) mechanism, coupled with 
the numbering of the RLC Data Blocks within one Temporary Block Flow. 

According to the link quality, an initial Modulation and Coding Scheme (MCS) is selected for an RLC block (see note). 
For the retransmissions, the same or another MCS from the same family of MCSs may be selected. E.g. if MCS-7 is 
selected for the first transmission of an RLC block, any MCS of the family B may be used for the retransmissions. 
Further, RLC data blocks initially transmitted with MCS4, MCS-5, MCS-6, MCS-7, MCS-8 or MCS-9, may be 
retransmitted with MCS-1, MCS-2 or MCS-3 as appropriate, by sending the different parts of the RLC data block in 
different radio blocks. In this case, the split block field in the header shall be set to indicate that the RLC data block is 
split, and the order of the two parts. For blocks initially transmitted with MCS-8 which are retransmitted using MCS-6 
or MCS-3, padding with all zeroes of the first six octets shall be applied as described in Annex J and the CPS field shall 
be set to indicate that this has been done. However, if the transmitter side is the mobile station and the RESEGMENT 
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bit is not set, the mobile station shall use an MCS within the same family as the initial MCS without splitting the 
payload (refer to sub-clause 8.1.1, table 8.1.1.1) for retransmission. 

In case an RLC data block originally transmitted using MCS-8 is retransmitted using two MCS-3 RLC/MAC blocks, 
the CPS field of the first MCS-3 RLC/MAC block shall indicate MCS-3 with padding while the CPS field of the second 
MCS-3 RLC/MAC block shall indicate either MCS-3 with padding or MCS-3 without padding. 

The selection of MCS is controlled by the network. 

The RLC data blocks shall first be sent with one of the initial code rates (i.e. the rate 1/3 encoded data is punctured with 
the Puncturing Scheme (PS) 1 of the selected MCS). If the RLC data block needs to be retransmitted, additional coded 
bits (i.e. the output of the rate 1/3 encoded data which is punctured with PS 2 of the prevailing MCS) shall be sent. If all 
the codewords (different punctured versions of the encoded data block) have been sent, the procedure shall start over 
and the first codeword (which is punctured with PS 1) shall be sent followed by PS 2 etc. RLC data blocks which are 
retransmitted using a new MCS shall at the first transmission after the MCS switch be sent with the puncturing scheme 
indicated in table 9.3.2. 1 . 1 . 

Table 9.3.2.1.1 : RLC data blocks re-transmitted in new MCS 



MCS 
switched from 


MCS 
switched to 


PS of last transmission 
before MCS switch 


PS of first transmission 
after MCS switch 


MCS-9 


MCS-6 


PS 1 or PS 3 


PS 1 


PS 2 


PS 2 


MCS-6 


MCS-9 


PS1 


PS 3 


PS 2 


PS 2 


MCS-7 


MCS-5 


any 


PS1 


MCS-5 


MCS-7 


any 


PS 2 


all other combinations 


any 


PS1 



This procedure allows the receiver to operate either in type I or type II hybrid ARQ mode. In the type I ARQ mode, 
decoding of an RLC data block is solely based on the prevailing transmission (i.e. erroneous blocks are not stored). In 
the type II ARQ case, erroneous blocks are stored by the receiver and a joint decoding with new transmissions is done. 
If the memory for IR operation run out in the mobile station, the mobile station shall indicate this by setting the MS 
OUT OF MEMORY bit in the EGPRS PACKET DOWNLINK ACK/NACK message or MBMS DOWNLINK 
ACK/NACK message (see note). For uplink TBFs, the network may implicitly set the type I mode by ordering the 
mobile station to use a specific MCS and setting the RESEGMENT bit or type II mode by ordering the mobile station to 
use a specific MCS and not setting the RESEGMENT bit. 

Type II hybrid ARQ is mandatory in EGPRS MS receivers and the associated performance requirements are specified 
in 3GPP TS 45.005/3GPP TS 45.009. Furthermore, it is mandatory for an EGPRS MS receiver to be able to perform 
joint decoding among blocks with different MCSs if the combination of MCSs is one of the following: 

- MCS-5 and MCS-7; 

- MCS-6 and MCS-9. 

NOTE: The MCS selection may take the IR capability of the receiver into account, for example by using a less 
robust MCS for a given channel quality. 



9.3.2.2 



Establishment of Temporary Block Flow 



The establishment of a TBF occurs as described in clause 7 and clause 8. RLC functions related to the ARQ function 
shall not operate until RLC data block transfer has been initiated. 

If the last uplink TBF ended with an incompletely transmitted upper layer PDU or any unacknowledged upper layer 
PDUs, the mobile station shall begin transmission on the new TBF with the oldest unacknowledged upper layer PDU. 



9.3.2.3 



Operation of uplink Temporary Block Flow 



The mobile station shall transmit an RLC/MAC block in each assigned uplink data block. RLC/MAC control blocks 
have preference to RLC data blocks, i.e. temporarily replacing the PDTCH with PACCH. 

The network shall send PACKET UPLINK ACK/NACK messages when needed. 
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The mobile station shall indicate a transmit window stall condition when V(S) = V(A) + WS. Upon detecting a transmit 
window stall condition, the mobile station shall set the Stall indicator (SI) bit in all subsequent uplink RLC data blocks 
for this TBF until the stall condition ceases to exist. 

Upon detecting the stall condition the mobile station shall also start timer T3182 for the TBF. Timer T3182 shall be 
stopped upon reception of a PACKET UPLINK ACK/NACK message that makes V(S) < V(A) + WS . If timer T3 1 82 
expires, the mobile station shall decrement counter N3102 by PAN_DEC, and proceed as follows: 

If there are no other ongoing uplink TBFs and one or no ongoing downlink TBFs perform an abnormal release 
with access retry (see sub-clause 8.7.2) (A/Gb mode) or 3GPP TS 44.160. 

If there one or more other ongoing uplink TBFs or multiple ongoing downlink TBFs, perform a multiple TBF 
abnormal release with access retry (see sub-clause 8.7.4). 

Whenever the mobile station receives a PACKET UPLINK ACK/NACK message that allows the advancement of V(S) 
or V(A), the mobile station shall increment N3102 by PAN_INC, however N3102 shall never exceed the value 
PAN_MAX. Upon cell reselection the mobile station shall set counter N3102 to the value PAN_MAX. When N3102 < 
is reached, the mobile station shall perform an abnormal release with cell re-selection (see sub-clause 9.4.2). If 
PAN_DEC or PAN_INC is set to the value 0, counter N3102 shall be disabled. 

A mobile station operating with an exclusive allocation shall start or restart timer T3184 upon reception of a 
PACKET UPLINK ACK/NACK message. If timer T3184 expires, the mobile station shall perform an abnormal release 
with access retry (see sub-clause 9.4.2). 

9.3.2.4 Release of uplink Temporary Block Flow 

9.3.2.4.1 General 

In the non-extended uplink TBF mode, the mobile station initiates the release of the uplink TBF by beginning the 
countdown process (see sub-clause 9.3.1). 

In the extended uplink TBF mode, the network determines when to release the uplink TBF. The release of an uplink 
TBF in the extended uplink TBF mode is performed by the procedure defined in sub-clause 9.5. 

9.3.2.4.2 Non-extended uplink TBF mode 

When the mobile station has sent the RLC data block with CV = and there are no elements in the V(B) array set to the 
value Nacked, it shall start timer T3182 for this TBF. The mobile station shall continue to send RLC data blocks on 
each assigned uplink data block, according to the algorithm defined in sub-clause 9.1.3. 

If the network has received all RLC data blocks when it detects the end of the TBF (i.e. when CV=0 and V(Q) = V(R)), 
it shall send the PACKET UPLINK ACK/NACK message with the Final Ack Indicator bit set to '1', include a valid 
RRBP field in the RLC/MAC control block header and clear counter N3103 for the TBF. The network may use the TBF 
Est field in the PACKET UPLINK ACK/NACK message to allow the mobile station to request the establishment of a 
new uplink TBF if there are no additional TBFs ongoing for that mobile station. 

If the network has not received all of the RLC data blocks when it detects the end of the TBF, it shall send a 
PACKET UPLINK ACK/NACK message to the mobile station and if necessary allocate sufficient uplink resources for 
the mobile station to retransmit the required RLC data blocks. 

Upon reception of a PACKET UPLINK ACK/NACK message for this TBF the mobile station shall stop timer T3182 
for the TBF. 

If the PACKET UPLINK ACK/NACK message has the Final Ack Indicator bit set to '1' and the following conditions 
are fulfilled: TBF Est field is set to '1'; the mobile station has new data to transmit; the mobile station has no other 
ongoing downlink TBFs, the mobile station shall release the uplink TBF and may request the establishment of a new 
TBF using one of the following procedures: 

If Control Ack Type parameter in System Information indicates acknowledgement is access burst, the mobile 
station shall transmit the PACKET CONTROL ACKNOWLEDGEMENT message with the Ctrl Ack bits set to 
'00'. The mobile station shall start timer T3168 for the TBF request and continue to monitor the PDCH used for 
transmitting the PACKET CONTROL ACKNOWLEDGEMENT message. The mobile station shall stop timer 
T3168 for the TBF upon reception of the PACKET UPLINK ASSIGNMENT message including Single Block 
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Allocation structure assigning resources for the TBF or the PACKET ACCESS REJECT message rejecting the 
TBF request. The mobile station shall use the same procedures as are used for TBF establishment using two 
phase access described in sub-clause 7. 1 .3 starting from the point where the mobile station receives the 
PACKET UPLINK ASSIGNMENT message including Single Block Allocation structure or the PACKET 
ACCESS REJECT message. 

If Control Ack Type parameter in System Information indicates acknowledgement is RLC/MAC control block, 
the mobile station shall transmit the PACKET RESOURCE REQUEST message and start timer T3168 for the 
TBF request. The mobile station shall use the same procedures as are used for TBF establishment using two 
phase access described in sub-clause 7. 1 .3 starting from the point where the mobile station transmits the 
PACKET RESOURCE REQUEST message. 

If the PACKET UPLINK ACK/NACK message has the Final Ack Indicator bit set to ' 1' and the mobile station does 
not initiate the establishment of a new uplink TBF according to one of the procedures described above, the mobile 
station shall transmit the PACKET CONTROL ACKNOWLEDGEMENT message and release the TBF. If there is no 
other ongoing TBFs, the mobile station in packet transfer mode or MAC-Shared state shall return to packet idle mode or 
MAC-Idle state; the mobile station in dual transfer mode or MAC-DTM state shall return to dedicated mode or MAC- 
Dedicated state. The DRX mode procedures shall be applied as specified in sub-clause 5.5.1.5 and 3GPP TS 44.160. If 
there are one or more ongoing TBFs a mobile station shall remain in its current mode/state and can request additional 
uplink TBFs as follows: 

- It may send a PACKET RESOURCE REQUEST message using the PACCH if there is at least one ongoing 
uplink TBF as described in sub-clause 8.1.1.1.2. 

It may include a Channel Request Description or the Extended Channel Request Description information 
element in the (EGPRS) PACKET DOWNLINK ACK/NACK message if there are no ongoing uphnk TBFs and 
at least one ongoing downlink TBF as described in sub-clause 8.1.2.5. 

If the PACKET UPLINK ACK/NACK message requests retransmission of RLC data blocks, the mobile station shall if 
necessary wait for allocation of uplink resources for this TBF and then retransmit the RLC data blocks requested. The 
mobile station shall then start timer T3182 for the TBF and wait for a PACKET UPLINK ACK/NACK message as 
above. 

If timer T3182 expires for the TBF the mobile station shall perform an abnormal release with access retry (see sub- 
clause 8.7.2) (A/Gb mode) or 3GPP TS 44.160. 

When the network receives the PACKET CONTROL ACKNOWLEDGEMENT message or the PACKET RESOURCE 
REQUEST message in the radio block indicated by the RRBP field, it may reuse the TFI and USE resources. 

If the network receives the PACKET CONTROL ACKNOWLEDGEMENT message with Ctrl Ack bits set to '00' or 
the PACKET RESOURCE REQUEST message in the radio block indicated by the RRBP field and the network has set 
the TBF Est field to '1' in the PACKET UPLINK ACK/NACK message, the network shall follow one of the following 
procedures: 

In case the mobile station requested the establishment of new TBF with the PACKET CONTROL 
ACKNOWLEDGEMENT message, the network shall respond to the mobile station with the 
PACKET UPLINK ASSIGNMENT message including Single Block Allocation structure or the PACKET 
ACCESS REJECT message on the same PDCH as the mobile station has sent the PACKET CONTROL 
ACKNOWLEDGEMENT message. TLLI (in A/Gb mode) or the G-RNTI (in lu mode) shall be used to identify 
the mobile station. The network shall use the same procedures as are used for TBF establishment using two 
phase access described in sub-clause 7.1.3 {A/Gb mode) or in 3GPP TS 44.160 starting from the point where the 
network transmits the PACKET UPLINK ASSIGNMENT message including Single Block Allocation structure 
or the PACKET ACCESS REJECT message. 

In case the mobile station requested the establishment of new TBF with the PACKET RESOURCE REQUEST 
message, the network shall use the same procedures as are used for TBF establishment using two phase access 
described in sub-clause 7.1.3 {A/Gb mode) or in 3GPPTS 44.160 starting from the point where the network has 
received the PACKET RESOURCE REQUEST message. TLLI {in A/Gb mode) or the G-RNTI (in lu mode) 
shall be used to identify the mobile station. 

If the network does not receive the PACKET CONTROL ACKNOWLEDGEMENT message or the PACKET 
RESOURCE REQUEST message in the radio block indicated by the RRBP field, it shall increment counter N3103 for 
the TBF and retransmit the PACKET UPLINK ACK/NACK message. If counter N3103 exceeds its limit, the network 
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shall start timer T3169 for the TBF. When timer T3169 expires for the TBF the network may reuse the TFI and USE 

resources. 

9.3.2.5 Operation of downlink Temporary Block Flow 

The mobile station receives RLC/MAC blocks on the assigned downlink PDCHs. On each assigned PDCH, the mobile 
station shall in the RLC header identify the TFI and decode the RLC data blocks intended for the mobile station. The 
operation during the TBF shall be as defined in sub-clause 9.1. 

9.3.2.6 Release of downlink Temporary Block Flow 

The network initiates the release of a downlink TBF by sending an RLC data block with the Final Block Indicator (FBI) 
set to the value '1' and with a valid RRBP field. The RLC data block sent must have the highest BSN' (see sub-clause 
9.3.1) of the downlink TBF. The network shall start timer T3191 for the TBF. While timer T3191 is running for the 
TBF the network may retransmit the RLC data block with the FBI bit set to the value '1'. For each retransmission the 
timer T3191 is restarted. 

In EGPRS TBF mode, if the final RLC data block is split for retransmission over two radio blocks (see sub-clause 
9.3.2.1), the network shall set the FBI to the value '1' in each part of the retransmitted RLC data block. 

If the mobile station receives an RLC data block (or, in EGPRS TBF mode, a part of a retransmitted RLC data block) 
with the FBI bit set the value '1' and with a valid RRBP field, the mobile station shall transmit a (EGPRS) 
PACKET DOWNLINK ACK/NACK message in the specified uphnk block. The mobile station shall continue to 
monitor all assigned PDCHs. 

Whenever the mobile station receives an RLC data block (or, in EGPRS TBF mode, a part of a retransmitted RLC data 
block) with a valid RRBP and the mobile station has received all RLC data blocks of the TBF, the mobile station shall 
send the (EGPRS) PACKET DOWNLINK ACK/NACK message with the Final Ack Indicator bit set to '1' in the 
reserved uplink radio block specified by the RRBP field, stop the timer T3 190 for the TBF. If the value of the timer 
T3192 is different from ms then the mobile station shall start or restart timer T3192 for the TBF and continue to 
monitor all assigned downlink PDCHs. Otherwise, if the value of timer T3192 was set to ms then the mobile station 
shall follow the same procedure as if the timer T3192 has expired. 

In GPRS TBF mode, if the mobile station receives more than one RLC data block with the FBI set to T, it shall accept 
the data from only the first one of these blocks. 

If the network receives a (EGPRS) PACKET DOWNLINK ACK/NACK message for the TBF before its timer T3 191 
expires, and if retransmissions are required, then the network stops timer T3191 for the TBF and retransmits necessary 
RLC data blocks according to the ARQ protocol before re -initiating the release of the downlink TBF. The FBI is set to 
T only if the RLC data block with the highest BSN' of the TBF is retransmitted. If no retransmission is required, the 
network shall stop timer T3191 for the TBF and start or restart timer T3193 for the TBF. When T3193 expires the 
network shall release the TBF. 

If timer T3191 expires for the TBF, then the network shall release the TBF. 

If the network has received the (EGPRS) PACKET DOWNLINK ACK/NACK message with the Final Ack Indicator 
bit set to '1' and has new data to transmit for the mobile station that cannot be transmitted on any ongoing downlink 
TBF, the network may establish one or more new downlink TBF(s) for the mobile station by sending on PACCH the 
PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET TIMESLOT 
RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE message with the Control Ack bit set to '1' for 
each TBF. The network may send these downlink assignment messages using the PACCH of any ongoing TBF for the 
mobile station. In case the network establishes a new downlink TBF for the mobile station using the PACCH of a 
downlink TBF for which T3193 is running, the network shall stop that instance of timer T3193 and release that TBF. 
The abnormal cases are described in sub-clause 8.1.2.4.1. 

If the mobile station, after sending the PACKET DOWNLINK ACK/NACK message with the Final Ack Indicator bit 
set to '1' for a given TBF, receives a PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK 
ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE message 
with the Control Ack bit set to '1' on the PACCH associated with this TBF while its timer T3192 is running, the mobile 
station shall stop this instance of timer T3192, consider this downlink TBF released and act upon the new assignments. 

When timer T3192 expires or its value was set to ms, the mobile station shall release the asssociated downlink TBF. If 
there are no other ongoing TBFs, the mobile station in packet transfer mode or MAC-Shared state shall return to packet 
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idle mode or MAC-Idle state; the mobile station in dual transfer mode respectively MAC-DTM state shall return to 
dedicated mode or MAC -Dedicated state. The DRX mode procedures shall be applied, as specified in sub-clause 5.5.1.5 
and 3GPP TS 44.160. If there are one or more ongoing TBFs a mobile station shall remain in its current mode/state and 
can request additional uplink TBFs as follows: 

- It may send a PACKET RESOURCE REQUEST message using the PACCH if there is at least one ongoing 
uplink THE as described in sub-clause 8.1.1.1.2. 

It may include a Channel Request Description or the Extended Channel Request Description information 
element in the (EGPRS) PACKET DOWNLINK ACK/NACK message if there are no ongoing uphnk TBFs and 
at least one ongoing downlink TBF as described in sub-clause 8.1.2.5. 

9.3.3 Unacknowledged mode operation 

9.3.3.0 General 

The transfer of RLC data blocks in the RLC unacknowledged mode does not include any retransmissions, except during 
the release of an uplink TBF where the last transmitted uplink block may be retransmitted (see sub-clause 9.3.3.3). In 
EGPRS TBF mode, retransmission with segmentation method shall not be used. The block sequence number (BSN) in 
the RLC data block header is used to number the RLC data blocks for reassembly. The receiving side sends Packet 
Ack/Nack messages in order to convey the necessary other control signalling (e.g. monitoring of channel quality for 
downlink transfer or timing advance correction for uplink transfers). 

9.3.3.1 Establishment of Temporary Block Flow 

If the last uplink TBF ended with an incompletely transmitted upper layer PDU, the mobile station shall begin 
transmission on the new TBF with the last incompletely transmitted upper layer PDU. 

9.3.3.2 Operation of uplink Temporary Block Flow 

The network shall send PACKET UPLINK ACK/NACK messages when needed. 

The mobile station shall set the Stall indicator (SI) bit to '0' in all RLC data blocks of the TBF. 

If the mobile station transmits the number of RLC data blocks corresponding to the RLC window size (WS), without 
receiving a Packet Ack/Nack message the mobile station shall start timer T3182 for the TBF. Timer T3182 shall be 
stopped upon reception of a PACKET UPLINK ACK/NACK message for this TBF. If timer T3 1 82 expires, the mobile 
station shall decrement counter N3102 by PAN_DEC, and perform an abnormal release with access retry (see sub- 
clause 8.7.2 (A/Gb mode) or 3GPP TS 44.160 sub-clause 8.8.3 (lu mode). 

Whenever the mobile station receives a PACKET UPLINK ACK/NACK message, the mobile station shall increment 
N3102 by PAN_INC, however N3102 shall never exceed the value PAN_MAX. Upon cell reselection the mobile 
station shall set counter N3102 to the value PAN_MAX. When N3102 < is reached, the mobile station shall perform 
an abnormal release with cell re-selection (see sub-clause 9.4.2). If PAN_DEC or PAN_INC is set to the value 0, 
counter N3102 shall be disabled. 

A mobile station operating with an exclusive allocation shall start or restart timer T3184 upon reception of a 
PACKET UPLINK ACK/NACK message. If timer T3184 expires, the mobile station shall perform an abnormal release 
with access retry (see sub-clause9.4.1). 

9.3.3.3 Release of uplink Temporary Block Flow 
9.3.3.3.1 General 

In the non-extended uplink TBF mode, the mobile station irutiates the release of the uplink TBF by beginning the 
countdown process (see sub-clause 9.3.1). 

In the extended uplink TBF mode, the network determines when to release the uplink TBF. The release of an uplink 
TBF in the extended uplink TBF mode is performed by the procedure defined in sub-clause 9.5 {A/Gb mode) or 
3GPPTS 44.160 (/MmoJe). 
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9.3.3.3.2 Non-extended uplink TBF mode 

The mobile station indicates the end of the TBF by sending the RLC data block with CV = 0. The mobile station shall 
start timer T3182 for the TBF. 

When the network detects the end of the TBF (i.e. when CV=0) it shall send a PACKET UPLINK ACK/NACK 
message with the Final Ack Indicator bit set to '1', include a valid RRBP field in the RLC/MAC control block header 
and clear counter N3103 for the TBF. The network may use the TBF Est field in the PACKET UPLINK ACK/NACK 
message to allow the mobile station to request the establishment of a new uplink TBF if there are no additional TBFs 
ongoing for that mobile station. 

In case the network receives multiple blocks with CV=0, only the first needs to be acknowledged with 
PACKET UPLINK ACK/NACK message. 

Upon reception of a PACKET UPLINK ACK/NACK message for this TBF the mobile station shall stop timer T3182 
for the TBF. 

If the PACKET UPLINK ACK/NACK message has the Final Ack Indicator bit set to ' 1' and the mobile station does 
not initiate the establishment of a new uplink TBF according to one of the procedures described below, the mobile 
station shall transmit the PACKET CONTROL ACKNOWLEDGEMENT message and release the TBF. If there are no 
other ongoing TBFs, the mobile station in packet transfer mode or MAC-Shared state shall enter packet idle mode or 
MAC-Idle state; the mobile station in dual transfer mode MAC-DTM state shall return to dedicated mode or MAC- 
Dedicated state. The DRX mode procedures shall be applied, as specified in sub-clause 5.5.1.5 and 3GPP TS 44.160. If 
there are one or more ongoing TBFs a mobile station shall remain in its current mode/state and can request additional 
uplink TBFs as follows: 

It may send a PACKET RESOURCE REQUEST message using the PACCH if there is at least one ongoing 
uplink TBF as described in sub-clause 8.1.1.1.2. 

It may include a Channel Request Description or the Extended Channel Request Description information 
element in the (EGPRS) PACKET DOWNLINK ACK/NACK message if there are no ongoing uplink TBFs and 
at least one ongoing downlink TBF as described in sub-clause 8.1.2.5. 

If the PACKET UPLINK ACK/NACK message has the Final Ack Indicator bit set to '1' and the following conditions 
are fulfilled: TBF Est field is set to '1'; the mobile station has new data to transmit; the mobile station has no other 
ongoing TBFs, the mobile station shall release the uplink TBF and may request the establishment of a new TBF using 
one of the following procedures: 

If Control Ack Type parameter in System Information indicates acknowledgement is access burst, the mobile 
station shall transmit the PACKET CONTROL ACKNOWLEDGEMENT message with the Ctrl Ack bits set to 
'00'. The mobile station shall start timer T3168 for the TBF request and continue to monitor the PDCH used for 
transmitting the PACKET CONTROL ACKNOWLEDGEMENT message. The mobile station shall stop timer 
T3168 for the TBF upon reception of the PACKET UPLINK ASSIGNMENT message including Single Block 
Allocation structure assigning resources for the TBF or the PACKET ACCESS REJECT message rejecting the 
TBF request. The mobile station shall use the same procedures as are used for TBF establishment using two 
phase access described in sub-clause 7.1.3 (A/Gb mode) or 3GPP TS 44.160 (/« mode) starting from the point 
where the mobile station receives the PACKET UPLINK ASSIGNMENT message including Single Block 
Allocation structure or the PACKET ACCESS REJECT message. 

If Control Ack Type parameter in System Information indicates acknowledgement is RLC/MAC control block, 
the mobile station shall transmit the PACKET RESOURCE REQUEST message and start timer T3168 for the 
TBF request. The mobile station shall use the same procedures as are used for TBF establishment using two 
phase access described in sub-clause 7.1.3 (A/Gb mode) or 3GPP TS 44.160 (lu mode) starting from the point 
where the mobile station transmits the PACKET RESOURCE REQUEST message. 

If the PACKET UPLINK ACK/NACK message does not have the Final Ack Indicator bit set to '1', the mobile station 
shall repeat sending the last block with CV=0, until a PACKET UPLINK ACK/NACK message with Final Ack 
Indicator bit set to '1' is received for this TBF. Upon each retransmission of the last block with CV=0, the mobile station 
shall restart timer T3182 for the TBF. The block with CV=0 shall not be retransmitted more than four times. If the 
medium access mode is dynamic allocation, the repetitions are transmitted when the mobile station is scheduled USFs. 
If timer T3 1 82 expires for the TBF the mobile station shall release the TBF as if a PACKET UPLINK ACK/NACK 
message was received. 
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When the network receives the PACKET CONTROL ACKNOWLEDGEMENT message or the PACKET RESOURCE 
REQUEST message in the radio block indicated by the RRBP field, it may reuse the TFI and USE resources. 

If the network receives the PACKET CONTROL ACKNOWLEDGEMENT message with Ctrl Ack bits set to '00' or 
the PACKET RESOURCE REQUEST message in the radio block indicated by the RRBP field and the network has set 
the TEE Est field to '1' in the PACKET UPLINK ACK/NACK message, the network shall follow one of the following 
procedures: 

In case the mobile station requested the establishment of new TBF with the PACKET CONTROL 
ACKNOWLEDGEMENT message, the network shall respond to the mobile station with the 
PACKET UPLINK ASSIGNMENT message including Single Block Allocation structure or the PACKET 
ACCESS REJECT message on the same PDCH as the mobile station has sent the PACKET CONTROL 
ACKNOWLEDGEMENT message. TLLI (in A/Gb mode) or G-RNTI (in lu mode) shall be used to identify the 
mobile station. The network shall use the same procedures as are used for TBF establishment using two phase 
access described in sub-clause 7.L3 (A/Gb mode) or 3GPP TS 44.160 (lu mode) starting from the point where 
the network transmits the PACKET UPLINK ASSIGNMENT message including Single Block Allocation 
structure or the PACKET ACCESS REJECT message. 

In case the mobile station requested the establishment of new TBF with the PACKET RESOURCE REQUEST 
message, the network shall use the same procedures as are used for TBF establishment using two phase access 
described in sub-clause 7.1.3 (A/Gb mode) or 3GPP TS 44.160 (lu mode) starting from the point where the 
network has received the PACKET RESOURCE REQUEST message. TLLI (in A/Gb mode) or G-RNTI (in lu 
mode) shall be used to identify the mobile station. 

If the network does not receive the PACKET CONTROL ACKNOWLEDGEMENT message or the PACKET 
RESOURCE REQUEST message for the TBF in the radio block indicated by the RRBP field, it shall increment counter 
N3103 and retransmit the PACKET UPLINK ACK/NACK message for the TBF. If counter N3103 exceeds its limit, the 
network shall start timer T3169 for the TBF. When timer T3169 expires for the TBF the network may reuse the TFI and 
USF resources. 

9.3.3.4 Operation of downlink Temporary Block Flow 

The mobile station receives RLC/MAC blocks on the assigned downlink PDCHs. On each assigned PDCH, the mobile 
station shall in the RLC header identify the TFI and decode the RLC data blocks intended for the mobile station. The 
operation during the TBF shall be as defined in sub-clause 9.1 (A/Gb mode) or 3GPP TS 44.160 (lu mode). 

9.3.3.5 Release of downlink Temporary Block Flow 

The network initiates the release of a downlink TBF by sending an RLC data block with the Final Block Indicator (FBI) 
set to the value '1' and with a valid RRBP field. The RLC data block sent must have the highest BSN' (see sub-clause 
9.3.1) of the downlink TBF. The network shall start timer T3191 for the TBF. The network may retransmit the last 
block with FBI set to the value '1' and with a valid RRBP field. For each retransmission for the TBF the timer T3191 is 
restarted. 

For each RLC data block with the FBI bit set to '1' and with a valid RRBP field, the mobile station shall transmit the 
PACKET CONTROL ACKNOWLEDGEMENT message in the uplink block specified by the RRBP field. The mobile 
station shall continue to read the assigned downlink PDCHs until the block period pointed to by the RRBP. If the 
mobile station receives more than one RLC data block with the FBI bit set to '1' and with valid RRBP fields that point 
the same uplink block period, the mobile station shall transmit the PACKET CONTROL ACKNOWLEDGEMENT 
message only once. The mobile station shall then stop timer T3190 for the TBF. If the value of timer T3192 is different 
from ms then the mobile station shall start timer T3192 for the TBF and continue to monitor all assigned downlink 
PDCHs. Otherwise, if the value of timer T3 192 was set to ms then the mobile station shall follow the procedure as if 
the timer T3192 has expired. 

If the mobile station then receives a subsequent RLC data block with a valid RRBP and the FBI bit set to '1', the mobile 
station shall retransmit the PACKET CONTROL ACKNOWLEDGEMENT message and restart timer T3192 for the 
TBF. 

In GPRS TBF mode, if the mobile station receives more than one RLC data block with the FBI set to '1' for the same 
RLC instance, it shall accept the data from only the first one of these blocks. 
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If the network receives the PACKET CONTROL ACKNOWLEDGEMENT message for the TBF before timer T3 191 
expires, the network shall stop timer T3191 for the TBF and start or restart timer T3193 for the TBF. When T3193 
expires the network shall release the TBF. 

If timer T3191 expires for the TBF, the network shall release the TBF. 

If the network has received the PACKET CONTROL ACKNOWLEDGEMENT message and has new data to transmit 
for the mobile station, the network may establish one or more new downlink TBF(s) for the mobile station by sending 
on PACCH the PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF DOWNLINK ASSIGNMENT, PACKET 
TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT RECONFIGURE message with the Control Ack bit set 
to '1' for each TBF. In case the network establishes a new downlink TBF for a mobile station that does not support 
multiple TBF procedures, the network shall stop timer T3193 for the TBF. 

If the mobile station, after sending the (EGRPS) PACKET DOWNLINK ACK/NACK message with the Final Ack 
Indicator bit set to '1' for a given TBF, receives a PACKET DOWNLINK ASSIGNMENT, MULTIPLE TBF 
DOWNLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or MULTIPLE TBF TIMESLOT 
RECONFIGURE message with the Control Ack bit set to '1' on the PACCH associated with this TBF while its timer 
T3192 is running, the mobile station shall stop this instance of timer T3192, consider this downlink TBF released and 
act upon the new assignments. 

When timer T3192 expires or its value was set to ms then the mobile station shall release the related downlink TBF. If 
there are no other ongoing TBF the mobile station in packet transfer mode or MAC-Shared state shall enter packet idle 
mode or MAC-Idle state; the mobile station in dual transfer mode or MAC-DTM state shall return to dedicated mode or 
MAC-Dedicated state. The DRX mode procedures shall be applied as specified in sub-clause 5.5.1.5, 3GPP TS 44.160. 
If there are one or more ongoing TBFs a mobile station shall remain in its current mode/state and can request additional 
uplink TBFs as follows: 

It may send a PACKET RESOURCE REQUEST message using the PACCH if there is at least one ongoing 
uplink TBF as described in sub-clause 8.1.1.1.2. 

It may include a Channel Request Description or the Extended Channel Request Description information 
element in the (EGPRS) PACKET DOWNLINK ACK/NACK message if there are no ongoing uphnk TBFs and 
at least one ongoing downlink TBF as described in sub-clause 8.1.2.5. 

9.3.4 Non-persistent mode operation 

9.3.4.0 General 

The transfer of RLC data blocks in RLC non-persistent mode includes non-exhaustive retransmissions. The block 
sequence number (BSN) in the RLC data block header is used to number the RLC data blocks for reassembly. The 
receiving side sends MBMS DOWNLINK ACK/NACK messages to inform the transmitting side of the status of the 
reception and to convey neighbouring cell measurements. 

9.3.4.1 Operation during an MBMS bearer 

The mobile station receives RLC/MAC blocks on the assigned downlink PDCHs. On each assigned PDCH, the mobile 
station shall in the RLC/MAC header identify the MBMS_BEARER_ID within the TFI field and decode the RLC data 
blocks if the mobile station is monitoring that MBMS Bearer. The operation during the MBMS bearer shall be as 
defined in sub-clause 9.1 

9.3.4.2 Release of an MBMS radio bearer 

The network may initiate the normal or abnormal release of an MBMS radio bearer by transmitting a PACKET TBF 
RELEASE message to the mobile station(s) on the PACCH, as described in sub-clause 8.1.4.4. 

The Final Block Indicator (FBI) bit shall not be set to the value '1' in any RLC/MAC block for data transfer of the 
MBMS radio bearer. 
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9.4 Abnormal release cases 

9.4.1 Abnormal release with access retry 

The procedure for abnormal release with access retry is defined in sub-clause 8.7.2. 

9.4.2 Abnormal release with cell reselection 

If the mobile station is not in dedicated mode of a circuit switched connection, or is in MAC-Shared state, the mobile 
station shall abort all TBFs in progress and return to packet idle mode or MAC -Idle state. The mobile station shall 
perform an abnormal cell reselection (see 3GPP TS 45.008) and initiate the establishment of one or more uplink TBFs, 
using the procedures on CCCH or PCCCH as defined in sub-clause 7.1 on the new cell. The mobile station shall not 
reselect back to the original cell for T_RESEL seconds if another suitable cell is available. 

If the abnormal cell reselection is abandoned (see 3GPP TS 45.008), the mobile station shall report an RLC/MAC 
failure to upper layers. If the mobile station remains in the cell where the abnormal release occurred, the DRX mode 
procedures shall be applied, as specified in sub-clause 5.5.1.5, 3GPP TS 44.160 sub-clause 5.4.1.8. 

If the mobile station is in dedicated mode of a circuit switched connection (applies in GPRS class A mode of operation) 
or is in MAC-DTM state, the mobile station shall perform an abnormal release without retry, defined in sub-clause 
8.7.1. 

The parameter T_RESEL (default value 5 s) is broadcast in PSI 3. 

9.5 Uplink TBF release in extended uplink TBF mode 

In the extended uplink TBF mode (see sub-clause 9.3.1b), the network may initiate the release an uplink TBF by 
sending a PACKET UPLINK ACK/NACK message with the Final Ack Indicator set to '1'. The network shall include a 
valid RRBP field in the RLC/MAC control block header and clear counter N3103 for the TBF. The network may use 
the TBF Est field in the PACKET UPLINK ACK/NACK message to allow the mobile station to request the 
establishment of new TBF. The release of the uplink TBF, using this procedure, may be initiated at a point determined 
by the network. 

If the PACKET UPLINK ACK/NACK message has the Final Ack Indicator bit set to '1' and the following conditions 
are fulfilled: TBF Est field is set to '1'; the mobile station has new data to transmit; the mobile station has no other 
ongoing TBFs, the mobile station shall release the uplink TBF and may request the establishment of a new TBF using 
one of the following procedures: 

If Control Ack Type parameter in System Information indicates acknowledgement is access burst, the mobile 
station shall transmit the PACKET CONTROL ACKNOWLEDGEMENT message with the Ctrl Ack bits set to 
'00'. The mobile station shall start timer T3168 for the TBF request and continue to monitor the PDCH used for 
transmitting the PACKET CONTROL ACKNOWLEDGEMENT message. The mobile station shall stop timer 
T3168 for the TBF upon reception of the PACKET UPLINK ASSIGNMENT message including Single Block 
Allocation structure assigning resources for the TBF or the PACKET ACCESS REJECT message rejecting the 
TBF request. The mobile station shall use the same procedures as are used for TBF establishment using two 
phase access described in sub-clause 7. 1 .3 starting from the point where the mobile station receives the 
PACKET UPLINK ASSIGNMENT message including Single Block Allocation structure or the PACKET 
ACCESS REJECT message. 

If Control Ack Type parameter in System Information indicates acknowledgement is RLC/MAC control block, 
the mobile station shall transmit the PACKET RESOURCE REQUEST message and start timer T3168 for the 
TBF request. The mobile station shall use the same procedures as are used for TBF establishment using two 
phase access described in sub-clause 7. 1 .3 starting from the point where the mobile station transmits the 
PACKET RESOURCE REQUEST message. 

If the PACKET UPLINK ACK/NACK message has the Final Ack Indicator bit set to '1' and the mobile station does not 
initiate the establishment of a new uplink TBF according to one of the procedures described above, the mobile station 
shall transmit the PACKET CONTROL ACKNOWLEDGEMENT message and release the TBF. If there are no other 
ongoing TBFs, the mobile station in packet transfer mode shall return to packet idle mode; the mobile station in dual 
transfer mode shall return to dedicated mode. The DRX mode procedures shall be applied as specified in sub- 
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clause 5.5.1.5. If there are one or more ongoing TBFs a mobile station shall remain in its current mode/state and can 
request additional uplink TBFs as follows: 

It may send a PACKET RESOURCE REQUEST message using the PACCH if there is at least one ongoing 
uplink THE as described in sub-clause 8.1.1.1.2. 

It may include a Channel Request Description or the Extended Channel Request Description information 
element in the (EGPRS) PACKET DOWNLINK ACK/NACK message if there are no ongoing uphnk TBFs and 
at least one ongoing downlink TBF as described in sub-clause 8.1.2.5. 

When the network receives the PACKET CONTROL ACKNOWLEDGEMENT message or the PACKET RESOURCE 
REQUEST message in the radio block indicated by the RRBP field, it may reuse the TFI and USE resources. 

If the network receives the PACKET CONTROL ACKNOWLEDGEMENT message with Ctrl Ack bits set to '00' or 
the PACKET RESOURCE REQUEST message in the radio block indicated by the RRBP field and the network has set 
the TBF Est field to '1' in the PACKET UPLINK ACK/NACK message, the network shall follow one of the following 
procedures: 

In case the mobile station requested the establishment of new TBF with the PACKET CONTROL 
ACKNOWLEDGEMENT message, the network shall respond to the mobile station with the 
PACKET UPLINK ASSIGNMENT message including Single Block Allocation structure or the PACKET 
ACCESS REJECT message on the same PDCH as the mobile station has sent the PACKET CONTROL 
ACKNOWLEDGEMENT message. TLLI shall be used to identify the mobile station. The network shall use the 
same procedures as are used for TBF establishment using two phase access described in sub-clause 7.1.3 starting 
from the point where the network transmits the PACKET UPLINK ASSIGNMENT message including Single 
Block Allocation structure or the PACKET ACCESS REJECT message. 

In case the mobile station requested the establishment of new TBF with the PACKET RESOURCE REQUEST 
message, the network shall use the same procedures as are used for TBF establishment using two phase access 
described in sub-clause 7.1.3 starting from the point where the network has received the PACKET RESOURCE 
REQUEST message. TLLI shall be used to identify the mobile station. 

If the network does not receive the PACKET CONTROL ACKNOWLEDGEMENT message or the PACKET 
RESOURCE REQUEST message for the TBF in the radio block indicated by the RRBP field, it shall increment counter 
N3103 and retransmit the PACKET UPLINK ACK/NACK message for the TBF. If counter N3103 exceeds its limit, the 
network shall stop scheduling new uplink resources for the TBF, stop sending the PACKET UPLINK ACK/NACK 
message to the mobile station and start timer T3169 for the TBF. 

When timer T3169 expires for the TBF, the network may reuse the TFI and USF resources. 



1 RLC/MAC block structure 
1 0.0a RLC/MAC block structure 

Different RLC/MAC block structures are defined for data transfers and for control message transfers. The RLC/MAC 
block structures for data transfers are different for GPRS and EGPRS, whereas the same RLC/MAC block structure is 
used for control message transfers. 

1 0.Oa.1 GPRS RLC/MAC block for data transfer 

The RLC/MAC block for GPRS data transfer consists of a MAC header and an RLC data block. The RLC data block 
consists of an RLC header, an RLC data unit and spare bits. 



RLC/MAC block 


MAC header 


RLC data block 


RLC header | RLC data unit 


Spare bits 



Figure 10.0a. 1.1 : RLC/MAC block structure for data transfer for GPRS 

The RLC data unit contains octets from one or more upper layer PDUs. 
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1 0.Oa.2 EGPRS RLC/MAC block for data transfer 

The RLC/MAC block for EGPRS data transfer consists of a combined RLC/MAC header and one or two RLC data 
blocks. 



RLC/MAC block 



RLC/MAC header 



RLC data block 1 



RLC data block 2 
(conditional) 



Figure 10.0a.2.1 : RLC/MAC block structure for data transfer for EGPRS 

Each RLC data blocks contain octets from one or more upper layer PDUs. 

Depending on the modulation and coding scheme (see 3GPP TS 44.004 and 3GPP TS 45.003) one or two RLC data 
blocks are contained in one RLC/MAC block. For MCS-1, MCS-2, MCS-3, MCS-4, MCS-5 and MCS-6 there is one 
RLC data block, whereas for MCS-7, MCS-8 and MCS-9 there are two RLC data blocks in the RLC/MAC block. 

In each transfer direction, uplink and downlink, three different header types are defined. Which header type that is used 
depends on the modulation and coding scheme (MCS): 

Header type 1 is used with modulation and coding scheme MCS-7, MCS-8 and MCS-9. 

Header type 2 is used with modulation and coding scheme MCS-5 and MCS-6. 

Header type 3 is used with modulation and coding scheme For MCS-1, MCS-2, MCS-3 and MCS-4. 

1 0.Oa.3 RLC/MAC block for control message transfer 

The RLC/MAC block for control message transfer consists of a MAC header and an RLC/MAC control block. 



RLC/MAC block 



IVIAC header RLC/MAC control block 



Figure 10.0a.3.1 : RLC/MAC block structure for control block 

1 0.Ob RLC/MAC block format conventions 
10.0b.1 Numbering convention 

The physical layer transfers RLC/MAC blocs, 11 -bit and 8-bit control messages in physical blocks of the packet data 
channel. The physical block formats are specified in 3GPP TS 44.004. The physical block is organised as a sequence of 
Nl octets that are numbered from 1 to Nl. An octet is a sequence of eight bits that are numbered from 1 to 8. If the total 
number of bits in a physical block is not an integer number of octets, the last bits of the physical block (in octet 
number Nl) does not form a complete octet. The bits that are transferred in the last, and possibly incomplete octet, are 
numbered from 1 to n, where 1 < n < 8. The total number of bits in the physical block is 8(N1 - 1) H- n. 

10.0b.2 Assembling conventions 

Different assembling conventions apply for GPRS RLC data blocks, RLC/MAC control blocks, 1 1-bit and 8-bit control 
messages and EGPRS RLC data blocks. 

1 0.Ob.2.1 Assembling convention for GPRS RLC data blocks and RLC/MAC control 
blocks, 1 1 -bit and 8-bit control messages 

The different components of an RLC/MAC block carrying a GPRS RLC data block or an RLC/MAC control block shall 
be assembled sequentially. Each component consists of an integer number of octets. The assembling of components 
shall be performed progressively, starting in octet number 1 of the physical block. 

The 1 1-bit and 8-bit control messages map directly into the corresponding physical block. 
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In this respect, an RLC/MAC control message, defined in sub-clause 1 1, or a segment of an RLC/MAC control 
message, see sub-clause 9.1.12a, shall be treated as a single field of either 176 bits (22 octets, using the 
PBCCH/PCCCH downUnk/PACCH block format), 1 1 bits or 8 bits (using the PRACH uplink/PACCH uplink short 
acknowledgement block formats, see 3GPP TS 44.004). The message contents defines a sequence of bits in decreasing 
order of value, i.e. the first bit of the message contents represents the highest order value and the last bit the lowest 
order value. 

The RLC/MAC header and a GPRS RLC data block are components that consist of an integer number of octets. Each 
octet shall be treated as a separate field when mapped into the physical block. The lowest numbered bit represents the 
lowest order value. 

The PDTCH block type 2 (CS-2), type 3 (CS-3) and type 4 (CS-4) formats (see 3GPP TS 44.004) do not have an 
integer number of octets. In these block types, bits number n to 1 of octet number Nl are spare bits. 

1 0.Ob.2.2 Assembling convention for EGPRS RLC data blocks 

The different components of the RLC/MAC block carrying an EGPRS RLC data block shall be assembled sequentially. 
A component may consist of a non-integer number of octets. Each octet shall be treated as a separate field when 
mapped into the physical block. The lowest numbered bit represents the lowest order value. 

The assembling of components shall be performed progressively, starting with octet number 1 of the physical block. If 
the boundary between two components falls within an octet of the physical block, the components, or parts thereof, that 
are contained in that octet shall be assembled progressively, starting with bit number 1 of the octet, (i.e. going from bit 
number 1 to bit number 8, except in octet number Nl, where components are assembled going from bit number 1 to bit 
number n). 

10.0b.3 Field mapping conventions 

Different field mapping conventions apply for GPRS RLC data blocks, RLC/MAC control blocks, 11 -bit and 8-bit 
control messages and EGPRS RLC data blocks. 

1 0.Ob.3.1 Field mapping convention for GPRS RLC data blocks, RLC/MAC control 
blocks, 1 1 -bit and 8-bit control messages 

When a field within a GPRS RLC data block or an RLC/MAC control block, or an 1 1-bit or an 8-bit control message is 
contained within a single octet of the physical block, the lowest numbered bit of the field represents the lowest order 
value. 

When a field spans more than one octet of the physical block, the order of bit values within each octet progressively 
decreases as the octet number increases. In that part of a field contained in a given octet, the lowest numbered bit 
represents the lowest order value. 

1 0.Ob.3.2 Field mapping convention for EGPRS RLC data blocks 

When a field within an EGPRS RLC data block is contained within a single octet of the physical block, the lowest 
numbered bit of the field represents the lowest order value. 

When a field spans more than one octet of the physical block, the order of bit values within each octet progressively 
increases as the octet number increases. In that part of a field contained in a given octet, the lowest numbered bit 
represents the lowest order value. 



10.1 Spare bits 



Where the description of RLC/MAC blocks in this Technical Specification contains bits defined to be 'spare bits', these 
bits shall set to the value '0' by the sending side, and their value shall be ignored by the receiving side. 
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1 0.2 GPRS RLC data blocks 

The RLC data block consists of an RLC header, an RLC data unit, and spare bits. An RLC/MAC block containing an 
RLC data block may be encoded using any of the available channel coding schemes CS-1, CS-2, CS-3, or CS-4 (see 
3GPP TS 45.003). RLC/MAC blocks encoded using CS-1 do not contain spare bits. The size of the RLC data block for 
each of the channel coding schemes is shown in table 10.2.1. 

Table 10.2.1 : RLC data block size 



Channel Coding 
Scheme 


RLC data block 

size without 

spare bits (N2) 

(octets) 


Number of 
spare bits 


RLC data 

block size 

(octets) 


CS-1 


22 





22 


GS-2 


32 


7 


32 7/8 


GS-3 


38 


3 


38 3/8 


GS-4 


52 


7 


52 7/8 



1 0.2.1 Downlink RLC data block 

The Downlink RLC data block together with its MAC header is formatted as shown in figure 10.2.1.1. 



Bit 
5 4 



Payload Type 


RRBP 


S/P 1 


USF 




PR 


TFI 


FBI 


BSN 


E 


Length indicator 




1 M 


E 




Length indicator 




1 M 


E 1 


RLC data 



IVIAC header 
Octet 1 
Octet 2 
Octet 3 (optional) 



Octet IVI (optional) 
Octet IVI+1 



Octet N2-1 
Octet N2 
(if present) 



spare spare 

Figure 10.2.1.1: Downlink RLC data block with MAC header 
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10.2.2 Uplink RLC data block 



The Uplink RLC data block together with its MAC header is formatted as shown in figure 10.2.2.1. 

Bit 
8 7 6 5 4 3 2 1 



NOTE: 



Payload Type 


Countdown Value 


SI 


R 


spare PI 


TFI 


Tl 


BSN 


E 


Length indicator 


M 


E 




Length indicator 


M 


E 1 


TLLI 


PFI 


1 


E 1 


RLC data 



spare 



spare 



MAC header 


Octet 1 


Octet 2 


Octet 3 (optional) 


Octet M (optional) 


Octet M+1 \ 


Octet M+2 } (optional) 


Octet M+3 / 


Octet M+4 / 


Octet IVI + 5 / 


Octet M+6 


Octet N-1 


Octet N 


(if present) 



The field mapping convention for GPRS (sub-clause 10.0b.3.1) applies. According to that, in particular 
regarding the TLLI field, the most significant byte of the TLLI value shall be mapped on octet IVI+I and the 
least significant byte of the TLLI value shall be mapped on octet M+4 of the uplink RLC data block. 

Figure 10.2.2.1: Uplink RLC data block with MAC header 



1 0.3 RLC/MAC control blocks 

The RLC/MAC control block consists of a control message contents field and in the downlink direction an optional 
control header. RLC/MAC control messages shall be transported within RLC/MAC control blocks. An RLC/MAC 
control blocks shall always be encoded using the coding scheme CS-1 (see 3GPP TS 44.004). 

1 0.3.1 Downlink RLC/MAC control block 

The Downlink RLC/MAC control block together with its MAC header is formatted as shown in figure 10.3.1.1. 



8 7 


Bit 
6 5 4 3 2 


1 




Payload Type 


RRBP S/P USF 




MAC header 


RBSN 


RTI FS 


AC 


Octet 1 (optional) 


PR 


1 TFI 


D 


Octet 2 (optional) 


RBSNe 


FSe spare 




Octet 2/3 (optional) see note 


Control Message Contents 


Octet M 

Octet 21 
Octet 22 


NOTE: This optional octet is included in case of ext 
segmentation. Its presence is indicated thro 
FS bit equal to (RBSN='1' and FS='0') 


ended F 
ugh the 


iLC/MAC control message 
combination of RBSN bit and 



Figure 10.3.1.1 : Downlink RLC/MAC control block together with its MAC header 
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1 0.3.2 Uplink RLC/MAC control block 



The Uplink RLC/MAC control block together with its MAC header is formatted as shown in figure 10.3.2.1. 



MAC header 
Octet 1 
Octet 2 
Octet 3 



8 7 


Bit 
6 5 4 3 


2 


1 


Payload Type 


spare 




R 1 


Control Message Contents 



Octet 21 
Octet 22 

Figure 10.3.2.1 : Uplink RLC/IUIAC control block together with its MAC header 

1 0.3a EGPRS RLC data blocks and RLC/MAC headers 
10.3a.O General 

The EGPRS RLC data block consists of a FBI (downlink) or TI (uphnk) field and an E field followed by an EGPRS 
RLC data unit The EGPRS RLC data unit is a sequence of N2 octets that are numbered from 1 to N2. 

NOTE: The octets of an EGPRS RLC data unit are not necessarily aligned with the octets of the RLC/MAC 

block. An octet of the EGPRS RLC data unit may thus span across the boundary between two consecutive 
octets of the RLC/MAC block. 

The RLC/MAC block format convention of sub-clause 10.0b for EGPRS applies when the components of the EGPRS 
RLC data block are assembled into the RLC/MAC block. 



FBI/TI 



EGPRS RLC data unit 



Figure lO.Sa.l : Components of the EGPRS RLC data block 

The size of the EGPRS RLC data unit for each of the channel coding schemes is shown in table 10.3a. 1. 

Table lO.Sa.l : EGPRS RLC data unit size 



Channel Coding Scheme 


EGPRS RLC data unit size (N2) 
(octets) 


Family 


MCS-1 


22 


C 


MCS-2 


28 


B 


MCS-3 


37 


A 


MCS-4 


44 


C 


MCS-5 


56 


B 


MCS-6 


74 


A 


MCS-7 


2x56 


B 


MCS-8 


2x68 


A 


MCS-9 


2x74 


A 


NOTE: The three families of EGPRS RLC data blocl<s based on a common 

size basis (22, 28 and 37 octets) enable link adaptation retransmission 
as described in sub-clause 9. 
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1 0.3a.1 EGPRS downlink RLC data block 

The EGPRS downlink RLC data blocks are formatted according to figure 10.3a.l.l. 





7 


Bit 
2 


1 


3 


2 


1 






1 FBI 1 


E 




8 


Bit 
6 5 


4 




Lengtii indicator 


E 


Octet 1 (note) 
(optional) 






Lengtii indicator 


E 


Octet IVI (optional) 


RLC data 


Octet M+1 

Octet N2-1 
Octet N2 



NOTE: 



If padding is used, then "Octet 1" shall be replaced by "Octet 7", see example in annex J. 
Figure 10.3a.1.1: EGPRS downlink RLC data block 



1 0.3a.2 EGPRS Uplink RLC data block 

The EGPRS uplink RLC data block are formatted according to figure 10.3a.2.1. 





Bit 




2 




1 


1 Tl 




E 1 



Bit 

5 4 



Length indicator 



Length indicator 



TLLI 



PFl 



RLC data 



Octet 1 (note 1) (optional) 



Octet M (optional) 
Octet M+1 \ 
Octet M+2 } (optional) 
Octet M+3 / 
Octet M+4 / 
Octet M+5 / 
Octet M+6 



Octet N2-1 
Octet N2 



NOTE 1 : If padding is used, then "Octet 1 " shall be replaced by "Octet 7", see example in annex J. 

NOTE 2: The field mapping convention for EGPRS (sub-clause 10.0b.3.2) applies. According to that, in particular 
regarding the TLLI field, the least significant byte of the TLLI value shall be mapped on octet M+1 and the 
most significant byte of the TLLI value shall be mapped on octet M+4 of the uplink EGPRS RLC data 
block. 

Figure 10.3a.2.1: Uplink EGPRS RLC data block 
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10.3a.3 EGPRS Downlink RLC/MAC header 

1 0.3a.3.1 Header type 1 : header for MCS-7, MCS-8 and MCS-9 

The EGPRS combined downlink RLC/MAC header for MCS-7, MCS-8 and MCS-9 (header type 1) is formatted 
according to figure 10. 3 a. 3. 1.1. 

Bit 

Octet 
1 
2 
3 
4 
5 

Figure 10.3a.3.1.1: EGPRS downlink RLC data block header 
for MCS-7, MCS-8 and MCS-9. 

1 0.3a.3.2 Header type 2: header for MCS-6 and MCS-5 

The EGPRS combined downlink RLC/MAC header for MCS-5 and MCS-6 (header type 2) is formatted according to 
figure 10.3a.3.2.1. 



Bit 
8 7 6 5 4 


3 


2 1 


TFI RRBP ES/P 




USF 


BSN1 PR 




TFI 


BSN1 1 


BSN2 




BSN1 


CPS 




BSN2 



Bit 
8 7 6 5 4 


3 2 


1 


TFI RRBP ES/P 


USF 1 


BSN1 PR 


TFI 




BSN1 1 


CPS 


BSN1 



Octet 
1 
2 
3 

4 



Figure 10.3a.3.2.1 : EGPRS downlink RLC data block header 
for MCS-5 and MCS-6. 



1 0.3a.3.3 Header type 3: header for MCS-4, MCS-3, MCS-2 and MCS-1 case 

The EGPRS combined downlink RLC/MAC header for MCS-1, MCS-2, MCS-3 and MCS-4 (header type 3) is 
formatted according to figure 10. 3a. 3. 3.1. 



Bit 
5 4 



TFI RRBP 




ES/P 


USF 


BSN1 


PR 




TFI 


BSN1 1 


SPB 




CPS 


BSN1 



Octet 
1 
2 
3 

4 



Figure 10.3a.3.3.1 : EGPRS downlink RLC data block header 
for MCS-1, MCS-2, MCS-3 and MCS-4. 
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8 7 


6 


Bit 
5 4 3 


2 


1 


TFI 


Countdown Value 


SI 


R 




BSN1 




TFI 




BSN2 




BSN1 






BSN2 1 


Spare PI 


RSB 1 


CPS 








Spare 



1 0.3a.4 EGPRS Uplink RLC/MAC header 

1 0.3a.4.1 Header type 1 : header for MCS-7, MCS-8 and MCS-9 

The EGPRS combined uplink RLC/MAC header for MCS-7, MCS-8 and MCS-9 (header type 1) is formatted 
according to figure 10.3a.4.1.1. 

Bit 

Octet 
1 
2 
3 
4 
5 
6 

Figure 10.3a.4.1.1: EGPRS uplink RLC data block header 
for MCS-7, MCS-8 and MCS-9. 

1 0.3a.4.2 Header type 2: header for MCS-6 and MCS-5 

The EGPRS combined upHnk RLC/MAC header for MCS-5 and MCS-6 (header type 2) is formated according to 
figure 10.3a.4.2.L 

Bit 

Octet 
1 
2 
3 
4 
5 

Figure 10.3a.4.2.1 : EGPRS uplink RLC data block header 
for MCS-5 and MCS-6 

1 0.3a.4.3 Header type 3 : header for MCS-4, MCS-3, MCS-2 and MCS-1 

The EGPRS combined upHnk RLC/MAC header for MCS-1, MCS-2, MCS-3 and MCS-4 (header type 3) is formatted 
according to figure 10.3a.4.3.1. 



8 7 


Bit 
6 5 4 3 


2 


1 


TFI 


Countdown Value 


SI 


R 




BSN1 


TFI 




CPS 


1 BSN1 






Spare | PI 


RSB 


CPS 




Spare 







8 7 


Bit 
6 5 4 3 


2 1 


TFI Countdown Value 


SI R 


BSN1 1 


TFI 


CPS 


BSN1 1 


Spare 


PI RSB SPB 


CPS 



Octet 
1 
2 
3 
4 



Figure 10.3a.4.3.1 : EGPRS uplink RLC data block header 
for MCS-1, MCS-2, MCS-3 and MCS-4. 



10.4 Header fields 

1 0.4.1 Uplink state flag (USF) field 

The USF field is sent in all downlink RLC/MAC blocks and indicates the owner or use of the next uplink radio block on 
the same timeslot (see 3GPP TS 45.002). The USF field is three bits in length and eight different USF values can be 
assigned, except on PCCCH, where the value '111' (USF=FREE) indicates that the corresponding uplink radio block 
contains PRACH. 
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10.4.2 Retry (R) bit 



The Retry (R) bit shall indicate whether the mobile station transmitted the CHANNEL REQUEST message (see 
3GPP TS 44.018), PACKET CHANNEL REQUEST message, EGPRS PACKET CHANNEL REQUEST message, or 
MPRACH PACKET CHANNEL REQUEST message one time or more than one time during its most recent channel 
access. The mobile station shall send the same value for the R bit in each uplink RLC/MAC block of the TBF. 

Table 10.4.2.1: Retry (R) bit 



biti 


Retry (R) bit 





MS sent channel request message once 


1 


MS sent channel request message twice or more 



10.4.3 Stall indicator (SI) bit 



The Stall indicator (SI) bit indicates whether the mobile's RLC transmit window can advance (i.e. is not stalled) or can 
not advance (i.e. is stalled). The mobile station shall set the SI bit in all uplink RLC data blocks. 

Table 10.4.3.1 : Stall indicator bit 



bit 2 


Stall indicator 





MS RLC transmit window is not stalled 


1 


MS RLC transmit window is stalled 



10.4.4 Supplementary/Polling (S/P) Bit 

The S/P bit is used to indicate whether the RRBP field is valid or not valid. 

Table 10.4.4.1 : Supplementary/Polling (S/P) bit - GPRS case and RLC/MAC control 



bit 4 


S/P 





RRBP field is not valid 


1 


RRBP field is valid 



10.4.4a EGPRS Supplementary/Polling (ES/P) Field 

The ES/P field is used to indicate whether the RRBP field is valid or not valid, and what fields the next uplink control 
block shall contain (see further clause 9). 

NOTE: The type of Ack/Nack bitmap requested by this field is applicable only when the next uplink control 
block is used to send an EGPRS PACKET DOWNLINK ACK/NACK or MBMS DOWNLINK 
ACK/NACK message. 

Table 10.4.4a.1 : EGPRS Supplementary/Polling (ES/P) field (non-MBMS only) 



bits 
54 


ES/P 


00 


RRBP field is not valid (no Polling) 


01 


RRBP field is valid - Extended Ack/Nack bitmap type FPB 


1 


RRBP field is valid - Extended Ack/Nack bitmap type NPB 


1 1 


RRBP field is valid - Ack/Nack bitmap type NPB, measurement report included 
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Table 10.4.4a.1 : EGPRS Supplementary/Polling (ES/P) field (MBMS only) 



bits 
54 


ES/P 


00 


RRBP field is not valid (no Polling) 


01 


RRBP field is valid - Extended Ack/Nack bitmap type FPB 


1 


RRBP field is valid - Extended Ack/Nack bitmap type NPB 


1 1 


RRBP field is valid - Extended Ack/Nack bitmap type NPB, 
measurement reports included 


neighbouring cell 



10.4.5 Relative Reserved Block Period (RRBP) field 

The RRBP value specifies a single uplink block in which the mobile station shall transmit either a PACKET 
CONTROL ACKNOWLEDGEMENT message or a PACCH block to the network. If the RRBP field is received as part 
of an RLC/MAC block containing an RLC/MAC control block, the mobile station shall transmit a PACKET 
CONTROL ACKNOWLEDGEMENT message in the uplink radio block specified, except if 

The received message is a Packet Paging Request, Packet Access Reject, or Packet Queueing 
Notificationmessage, or 

It is specified elsewere that the mobile station shall not respond to the polling request. 

If the RRBP field is received as part of an RLC/MAC block containing an RLC/MAC control block containing a Packet 
Paging Request, Packet Access Reject, or Packet Queueing Notification message, or it is specified elsewere that the 
mobile station shall not respond to the polling request, the mobile station shall ignore this RRBP field. The mobile 
station shall only react on RLC/MAC control blocks containing a valid RRBP field if the mobile station is addressed 
either in the downlink RLC/MAC control block header or in the control message itself. If the control message is 
segmented into more than one downlink RLC/MAC control blocks the mobile station shall react only on RLC/MAC 
control blocks containing a valid RRBP field if the mobile station is addressed in the downlink RLC/MAC control 
block header. 

If the mobile station receives two or more RLC/MAC blocks containing an RLC/MAC control message with different 
RRBP values such that they specify the same uplink block, the mobile station shall transmit one PACKET CONTROL 
ACKNOWLEDGEMENT message in the specified uplink radio block. 

If the RRBP field is received as part of a RLC/MAC block containing an RLC data block, the mobile station shall 
transmit a PACCH block in the specified uplink radio block. If the mobile station receives two or more RLC/MAC 
blocks containing an RLC data block with different RRBP values such they specify the same uplink radio block, the 
mobile station shall transmit one PACCH block in the specified uplink radio block. 

If the mobile station receives an RLC data block and an RLC/MAC control block with different RRBP values such that 
they specify the same uplink radio block, the mobile station shall transmit an PACKET CONTROL 
ACKNOWLEDGEMENT message in the specified uplink radio block. 

The mobile station shall either transmit the uplink radio block on the same timeslot as the block where the RRBP was 
received or, if an UPLINK_CONTROL_TIMESLOT is assigned to the mobile station, the mobile station shall transmit 
the uplink radio block on this UPLINK_CONTROL_TIMESLOT. After receiving an RLC/MAC block containing a 
valid RRBP field the mobile station need not monitor the USE in the associated downlink RLC/MAC block appearing 
just before the uplink block it shall transmit. However, when Extended Dynamic Allocation or Shifted USE operation is 
used, the corresponding USE monitoring procedure shall apply as described in sub-clause 8.1.1.2.1 and sub-clause 
8.1.1.2.4 respectively. 

A polled control message shall always be sent in the uplink block specified by the corresponding valid RRBP field of a 
downlink RLC/MAC control block, and not in any other uplink block that may be allocated to the mobile station. 

The network should not use the RRBP field to schedule the transmission of a PACKET CONTROL 
ACKNOWLEDGEMENT message or an uplink PACCH block later than the second last block, B(x-2) mod 12, before 
the first block, B(x), where the mobile station shall be ready to transmit and receive using a new assignment. A mobile 
station that is scheduled an uplink block later than that may omit responding to the polling request or may delay the 
access using the new assignment, in order to respond to the polling request. 

The network should not use the RRBP field to schedule the transmission of PACKET CONTROL 
ACKNOWLEDGEMENT messages or uplink PACCH blocks, in such way, that a mobile station has more than three 
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such uplink blocks pending for transmission at any instant. A mobile station, that is scheduled such uplink blocks more 
frequent than that, may omit responding to the excessive polling requests. 

Table 10.4.5.1 indicates the number of TDMA frames the mobile station shall wait before transmitting the uplink 
RLC/MAC block. The delay is relative to the first TDMA frame (N) of the downlink block containing the RRBP value. 
For definition of TDMA frame numbering, see 3GPP TS 45.002. 

Table 10.4.5.1 : Relative Reserved Block Period (RRBP) field 



bit 
6-5 


Full-rate PDCH uplink block with 
TDMA frame number 


Half-rate PDCH uplink block with 
TDMA frame number 


00 


(N+13) mod 2715648 


reserved 


1 


(N+17 or N+18) mod 2715648 


(N+17 or N+18) mod 271 5648 


1 


(N+21 or N+22) mod 271 5648 


reserved 


1 1 


(N+26) mod 271 5648 


(N+26) mod 271 5648 



If the mobile station is operating on a half-rate PDCH and it receives an RLC/MAC block with a reserved RRBP value, 
it shall regard the RRBP field as not valid and shall ignore the polling. 

10.4.5.1 Special requirements in dual transfer mode 

If the mobile station in dual transfer mode is using PDCH/H, where the exclusive allocation is required, special 
requirements apply when the mobile station receives a valid RRBP field in a downlink RLC/MAC block: 

The mobile station may disregard the actual value of a valid RRBP field. The mobile station shall respond to the 
polling request at the TDMA frame number specified by one of the allowed RRBP values, regardless of which 
value that was actually received. 

If the mobile station receives more than one RLC/MAC block with a valid RRBP field, the mobile station shall 
respond to each one of the polling requests with a separate PACKET CONTROL ACKNOWLEDGEMENT 
message or PACCH block to the network. 

- When the mobile station responds with a PACKET CONTROL ACKNOWLEDGEMENT message to a valid 
RRBP field, the mobile station shall use the RLC/MAC control block format. That is regardless of the 
CONTROL_ACK_TYPE parameter received in the broadcast information of the cell or the TYPE_OF_ACK 
parameter received in a PACKET POLLING REQUEST message. 

If the mobile station in dual transfer mode is not using PDCH/H, the normal requirements apply when the mobile 
station receives a valid RRBP field in a downlink RLC/MAC block. 



1 0.4.6 Countdown Value (CV) field 



The Countdown Value (CV) field is sent by the mobile station to allow the network to calculate the number of RLC 
data blocks remaining for the current uplink RLC entity. The CV value shall be calculated according to the process 
described in sub-clause 9.3.1. The CV field is 4 bits in length and is encoded as a binary number with range to 15. 
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1 0.4.7 Payload Type field 



The Payload Type field shall indicate the type of data contained in remainder of the RLC/MAC block. The encoding of 
the Payload Type field is shown in table 10.4.7.1. 



Table 10.4.7.1 : Payload Type field 



bit 
87 



Payload Type 



00 



RLC/MAC block contains an RLC data block 



01 



RLC/MAC block contains an RLC/MAC control block that does not include the optional octets 
of the RLC/MAC control header 



10 



In the downlink direction, the RLC/MAC block contains an RLC/MAC control block that 

includes the optional first octet of the RLC/MAC control header. 

In the uplink direction, this value is reserved. 



1 1 



Reserved. In this version of the protocol, the mobile station shall ignore all fields of the 
RLC/MAC block except for the USF field 



1 0.4.8 Final block indicator (FBI) bit 



The Final block indicator (FBI) bit indicates that the downlink RLC data block is the last RLC data block of the 
downlink TBF. 

Table 10.4.8.1: Final block indicator bit 



bit1 


Final block indicator 





Current block is not last RLC data block in TBF 


1 


Current block is last RLC data block in TBF 



1 0.4.8a Coding and Puncturing Scheme indicator field (CPS) 

In EGPRS header, the Coding and Puncturing Scheme indicator field is used to indicate the kind of channel coding and 
puncturing used for data blocks (see 3GPP TS 45.003). 
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10.4.8a.1 Header type 1 : 

Table 10.4.8a.1 .1 : Coding and Puncturing Scheme indicator field for Header type 1 



bits 
54321 


CPS 


00000 


{MCS-9/P1 


MCS-9/P1) 


00001 


{MCS-9/P1 


MCS-9/P2) 


00010 


(MCS-9/P1 


MCS-9/P3) 


00100 


{MCS-9/P2 


MCS-9/P1) 


00101 


{MCS-9/P2 


MCS-9/P2) 


00110 


{MCS-9/P2 


MCS-9/P3) 


01000 


(MCS-9/P3 


MCS-9/P1) 


01001 


(MCS-9/P3 


MCS-9/P2) 


01010 


{MCS-9/P3 


MCS-9/P3) 


01011 


{MCS-8/P1 


MCS-8/P1) 


01100 


{MCS-8/P1 


MCS-8/P2) 


01101 


(MCS-8/P1 


MCS-8/P3) 


01110 


(MCS-8/P2 


MCS-8/P1) 


01111 


{MCS-8/P2 


MCS-8/P2) 


10000 


{MCS-8/P2 


MCS-8/P3) 


10001 


{MCS-8/P3 


MCS-8/P1) 


10010 


(MCS-8/P3 


MCS-8/P2) 


10011 


(MCS-8/P3 


MCS-8/P3) 


10100 


{MCS-7/P1 


MCS-7/P1) 


10101 


{MCS-7/P1 


MCS-7/P2) 


10110 


{MCS-7/P1 


MCS-7/P3) 


10111 


(MCS-7/P2 


MCS-7/P1) 


11000 


(MCS-7/P2 


MCS-7/P2) 


11001 


{MCS-7/P2 


MCS-7/P3) 


11010 


{MCS-7/P3 


MCS-7/P1) 


11011 


{MCS-7/P3 


MCS-7/P2) 


11100 


(MCS-7/P3 


MCS-7/P3) 




All the other values are reserved for future use 


NOTE: The bit numbering is relative to the field position. 



10.4.8a.2 Header type 2 

Table 10.4.8a.2.1 : Coding and Puncturing Scheme indicator field for Header type 2 



bits 
321 


(first block) 
CPS 


000 


MCS-6/P1 


001 


MCS-6/P2 


010 


MCS-6/P1 with padding (MCS-8 retransmission) 


011 


l\/ICS-6/P2 with padding (MCS-8 retransmission) 


100 


MCS-5/P1 


101 


MCS-5/P2 




All the other values are reserved for future use 


NOTE: The bit numbering is relative to the field position. 
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10.4.8a.3 Header type 3 

Table 10.4.8a.3.1 : Coding and Puncturing Scheme indicator field for Header type 3 



bits 
4321 


First block 
CPS 


0000 


MCS-4/P1 


0001 


MCS-4/P2 


0010 


MCS-4/P3 


0011 


MCS-3/P1 


0100 


MCS-3/P2 


0101 


MCS-3/P3 


0110 


IVICS-3/P1 with padding (MCS-8 retransmission) 


0111 


MCS-3/P2 with padding (IVICS-S retransmission) 


1000 


MCS-3/P3 with padding (IVICS-S retransmission) 


1001 


MCS-2/P1 


1010 


MCS-2/P2 


1011 


MCS-1/P1 


1100 


MCS-1/P2 




All the other values are reserved for future use 


NOTE: The bit numbering is relative to the field position. 



1 0.4.8b Split Block indicator field (SPB) 

In EGPRS, the Split Block indicator is only used in header type 3 to indicate if some user data is retransmitted using 2 
block resegmentation (see clause 9). 

Table 1 0.4.8b. 1 : Split Block indicator field 



bits 
21 


SPB 


00 


No retransmission 


1 


Reserved 


1 


Retransmission - first part of block 


1 1 


Retransmission - second part of block 


NOTE: 


The bit numbering is relative to the field position. 



10.4.9 TLLI Indicator (Tl) bit 

The TLLI Indicator (TI) bit indicates the presence of an optional TLLI/G-RNTI field within the RLC data block. 

Table 10.4.9.1 : TLLI Indicator (Tl) bit 



bit1 


TLLI indicator (Tl) bit 





TLLI/G-RNTI field is not present 


1 


TLLI/G-RNTI field is present 



1 0.4.9a Address Control (AC) bit 

The Address Control (AC) bit is used to indicate the presence of the optional TFI/D octet in the header of downlink 
RLC/MAC control blocks. 

Table 10.4.9a.1 : Address Control (AC) bit 



bit1 


Address Control (AC) bit 





TFI/D octet is not present 


1 


TFI/D octet is present 
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10.4.9b Final Segment (FS) bit 

The Final Segment (FS) bit indicates that the downlink RLC/MAC control block contains the final segment of an 
RLC/MAC control message except when it is sent using extended RLC/MAC control message segmentation. In case of 
extended RLC/MAC control message segmentation, the final segment of an RLC/MAC control message is indicated 
with the FSe bit as defined in sub-clause 10.4.9e while the FS bit is set to '0' (see sub-clauses 9.1.12a and 10.4.12b). 

Table 10.4.9b.1 : Final Segment (FS) bit 



bit 2 


Final Segment (FS) bit 





Current block does not contain the final segment of an 
RLC/IVIAC control message 


1 


Current block contains the final segment of an 
RLC/MAC control message 



1 0.4.9c Radio Transaction Identifier (RTI) field 

The Radio Transaction Identifier (RTI) field is used to group the downlink RLC/MAC control blocks that make up an 
RLC/MAC control message and identifies the segmented control message sequence with which the downlink 
RLC/MAC control block is associated. The RTI field is five bits in length with range to 3 1 . 

10.4.9d Direction (D) bit 

The Direction (D) bit indicates the direction of the TBF identified by the TFI field in the downlink RLC/MAC control 
block header. 

Table 10.4.9d.1: Direction (D) bit 



biti 


Direction (D) bit 





TFI field identifies an uplink TBF 


1 


TFI field identifies a downlink TBF 



1 0.4.9e Final Segment extension (FSe) bit 

The Final Segment extension (FSe) bit indicates that the downlink RLC/MAC control block contains the final segment 
of an RLC/MAC control message segmented using extended RLC/MAC control message segmentation (see sub-clauses 
9.1.12a and 10.4.12b). The FSe bit is only present from the second RLC/MAC control block onwards. 

Table 10.4.9e.1 : Final Segment extension (FSe) bit 



bits 


Final Segment extension (FSe) bit 





Current block does not contain the final segment of an 
RLC/IVIAC control message 


1 


Current block contains the final segment of an 
RLC/IVIAC control message 
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1 0.4.1 Temporary Flow Identity (TFI) field 

In RLC data blocks, the TFI identifies the Temporary Block Flow (TBF) to which the RLC data block belongs. For the 
downlink and the uplink TFI the TFI field is 5 bits in length and are encoded as a binary number with range to 3 1 .In 
downlink RLC/MAC control blocks, the TFI identifies the Temporary Block Flow (TBF) to which the RLC/MAC 
control message contained in the downlink RLC/MAC control block relates. If present, this field indicates the mobile 
station to which the control message is addressed; all other mobile stations shall analyse the distribution contents, 
depending on their protocol state, as specified in clauses 5 and 7 of the present document. If this field is present and the 
contents of the control message also contain a TFI addressing the mobile station, the mobile station shall ignore the TFI 
in the control message contents. If this field is not present all mobile stations shall interpret the contents of the control 
message. 

10.4. 10a Power Reduction (PR) field 

The Power Reduction (PR) field indicates the power level reduction of the current RLC block. 

The coding of Power Reduction (PR) field is shown in Table 10.4.10a.l. There is one value of the PR field which 
indicates that the field shall be ignored by the MS. 

If downlink power control is not used, the MS shall ignore the PR field. 

If downlink power control is used and the PR field is not included in a downlink RLC/MAC control block, the MS shall 
act as if the block contained a usable PR field with value '0 0'. 

Table 10.4.10a.1: Power Reduction (PR) field 



bit 
87 


Power Reduction 


00 


dB (included) to 3 dB (excluded) less than BCCH level - PO 


01 


3 dB (included) to 7 dB (excluded) less than BCCH level - PO 


1 


7 dB (included) to 10 dB (included) less than BCCH level - PO 


1 1 


Not usable 



10.4.11 Extension (E) Bit 

The Extension (E) bit is used to indicate the presence of an optional octet in the RLC data block header. 

Table 10.4.11.1: Extension (E) bit 



bit1 


Ebit 





Extension octet follows immediately 


1 


No extension octet follows 



In A/Gb mode, extension (E) bit after the PFI field is used for extensions of the protocol by allowing optional octets in 
the RLC data block header. However, when extensions of this protocol are developed, networks will treat all unknown 
optional octets as spare until the E bit of 1 . 

1 0.4.1 2 Block Sequence Number (BSN) field 

The Block Sequence Number (BSN) field carries the sequence absolute Block Sequence Number (BSN') modulo 
Sequence Number Space (SNS) (128 in GPRS and 2 048 in EGPRS ) of each RLC data block within the TBF. 

In GPRS, the BSN is 7 bits in length and is encoded as a binary number with range to 127. 

In EGPRS, the BSN is 11 bits in length and is encoded as a binary number with range to 2 047. 

In case two RLC data blocks are sent within a RLC/MAC block, BSN2 is relative to BSNl, provided the difference 
between the second block number and the first block modulo SNS is less than Window Size (WS). 

Second block number = [BSNl + BSN2] modulo SNS 
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(e.g. SNS = 2 048, WS = 512, Block A block number = 10 and Block B block number= 2 000 then: 

[Block A - Block B] modulo SNS = 58 < 512; 

[Block B - Block A] modulo SNS = 1 990 > 512; 

Then; Block #1 = Block B and Block #2 = Block A, BSNl = 2 000 and BSN2 = 58). 

1 0.4.1 2a Reduced Block Sequence Number (RBSN) bit 

The Reduced Block Sequence Number (RBSN) bit carries the sequence number of the downlink RLC/MAC control 
blocks. The RBSN bit is encoded as a binary number with range to 1. 

10.4.1 2b Reduced Block Sequence Number extension (RBSNe) field 

The Reduced Block Sequence Number extension (RBSNe) field together with the RBSN bit indicate the sequence 
number of the downlink RLC/MAC control blocks of an RLC/MAC control message segmented using extended 
RLC/MAC control message segmentation. The RBSNe field is encoded as a binary number with range to 7. Along 
with the FS bit and the FSe bit, they allow for extended RLC/MAC control message segmentation as shown in table 
10.4.12b.l (see sub-clause 9.1.12a). 

Table 10.4.12b.1 : RBSN bit, FS bit, RBSNe field, FSe bit 



RBSN 


FS 


RBSNe 


FSe 










N/A 


N/A 


1" RLC/MAC control block 







000 





2"" RLC/MAC control block 







001 


0/1 


3'° 1 last RLC/MAC control block 







1 


0/1 


4'" / last RLC/MAC control block 







1 1 


0/1 


5'"/last RLC/MAC control block 







1 00 


0/1 


6'7last RLC/MAC control block 







1 01 


0/1 


/"/last RLC/MAC control block 







1 1 


0/1 


8'"/last RLC/MAC control block 







1 1 1 


1 


9'" and last RLC/MAC control block 



10.4.13 More (M) bit 



In GPRS TBF mode, the M bit, along with the E bit and the Length Indicator (LI), are used to delimit LLC PDUs within 
a TBF. When the M bit is present it indicates whether or not another LLC PDU follows the current one within the RLC 
data block. The function of the M and E bits when they occur in the same octet is defined in table 10.4.13.1. 

In EGPRS TBF mode the M bit is not used, instead a special combination of the LI field is used to indicate presence of 
following LLC PDUs. 

Table 10.4.13.1 : M bit and E bit 



bit 
ME 



00 



In lu mode, the RLC data block belongs to the signalling radio bearer identified by SRBid 
(see 3GPP TS 44.160). In A/Gb mode, if received by the mobile station it shall ignore all 
fields of the RLC/MAC block except for the fields of the MAC header 



01 



no LLC data after the current LLC PDU, no more extension octets 



1 



a new LLC PDU starts after the current LLC PDU and there is another extension octet, 
which delimits the new LLC PDU 



1 1 



a new LLC PDU starts after the current LLC PDU and continues until the end of the RLC 
information field, no more extension octets 
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1 0.4.1 4 Length Indicator (LI) field in GPRS TBF mode and DCCH TBF mode 
{lu mode) 

The Length Indicator is used to delimit Upper Layer PDUs within the RLC data block. Additionally for lu mode, a 
Length Indicator of value 63 may be used to indicate the presence of filler information within the RLC data block. If the 
first length indicator in the RLC data block is set to 63, then the entire RLC data block contains filler information. 

The first Length Indicator shall indicate the number of octets of the RLC data field belonging to the first Upper Layer 
PDU, the second Length Indicator shall indicate the number of octets of the RLC data field belonging to the second 
Upper Layer PDU, etc. Only the last segment of any Upper Layer PDU of a TBF (either this segment carries the entire 
Upper Layer PDU or not) shall be identified with a Length Indicator within the corresponding RLC data block. 

A singular case occurs when the end of the Upper Layer PDU would fit within the RLC data block but the addition of 
the Length Indicator octet (to indicate the Upper Layer PDU boundary) causes the Upper Layer PDU to extend into the 
next RLC data block. In this case, this additional LI field shall take the value whatever is the length of the last but one 
Upper Layer PDU segment. 

The final RLC data block of a TBF shall have a Length Indicator field corresponding to the final Upper Layer PDU 
unless this PDU fills the RLC data block precisely without the LI field being added (i.e. the singular case mentioned 
above never applies in this situation). 

The final RLC data block of an uplink TBF shall have a Length Indicator field with the value if the final Upper Layer 
PDU is incompletely transmitted by the mobile station. 

The LI field is 6 bits in length and shall be encoded as a binary number with range 1 to 19, 29, 35 or 49, according to 
the coding scheme in use, i.e. CS-1, CS-2, CS-3 or CS-4 respectively. The value shall indicate that no Upper Layer 
PDU boundary exists. In this case the M bit shall be set to' 0' and the E bit shall be set to '1' on the transmitting side, 
while on the receiving side the M bit shall be ignored and the E bit shall be interpreted as having the value T. In lu 
mode, a value of 63 shall indicate the presence of filler information within the RLC data block. All other values are 
reserved, and in this version of the protocol, the mobile station shall ignore all fields of the RLC data block except for 
the USF field. 

10.4.1 4a Length Indicator (LI) field in EGPRS TBF mode and TCH TBF mode 
{iu mode) 

The Length indicator is used to delimit Upper Layer PDUs within the RLC data block. Additionally for lu mode, a 
Length Indicator of value 127 may be used to indicate the presence of filler information within the RLC data block. If 
the first length indicator in the RLC data block is set to 127, then the entire RLC data block contains filler information. 

The first Length Indicator shall indicate the number of octets of the RLC data field belonging to the first Upper Layer 
PDU, the second Length Indicator shall indicate the number of octets of the RLC data field belonging to the second 
Upper Layer PDU, etc. Only the last segment of any Upper Layer PDU, including those with only one segment, shall be 
identified with a Length Indicator The length indicator shall be placed in the RLC data block corresponding to the last 
segment of the Upper Layer PDU, unless the Upper Layer PDU without the corresponding LI field fills the RLC data 
block precisely. In that case, the Length Indicator shall be placed as the first Length Indicator in the next in sequence 
RLC data block and take the value 0. 

If the Upper Layer PDU does not fill the current RLC data block, a Length Indicator with value 127 (111 1111) shall be 
included as the last Length Indicator of the current RLC data block, indicating that there is no following Upper Layer 
PDU in this RLC data block. If the Upper Layer PDU does not fill the RLC data block and there is only one octet left, 
then the Length Indicator corresponding to the Upper Layer PDU is the last Length Indicator field that shall be included 
in the RLC data block. In case an Upper Layer PDU cannot be transmitted completely in the current RLC data block 
and will not be continued in the next in-sequence RLC data block, the corresponding Length Indicator shall have the 
value 127. 

The final RLC data block of a TBF shall have a Length Indicator field corresponding to the final Upper Layer PDU 
unless the final Upper Layer PDU fills the RLC data block precisely. If the final Upper Layer PDU fills the final RLC 
data block precisely, the final Upper Layer PDU shall be sent without a corresponding Length Indicator field. 

The Length Indicator field is 7 bits in length and shall be encoded as a binary number. The valid values are the values 
ranging from to 74 in EGPRS TBF mode, from to 103 in TCH TBF mode {lu mode), and the value 127. All other 
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values are reserved. A mobile station detecting a reserved Length Indicator value or an inconsistent encoding of the 
Length Indicator and E fields shall ignore the RLC data block. 

The interpretation of the value contained in the length indicator with corresponding E bit is summarized in 
table 10.4. 14a. 1 and some examples are shown in annex B. 

Table 1 0.4.1 4a.1 : Interpretation of values of LI field and E bit 



Value of LI in a RLC data 
block 



Value of E bit in 
the same octet 



Interpretation 



k-th LI: 

0< value <75 (EGPRS) 
0< value <1 04 (TCH) 
(k>0 integer) 



The value of the k-th LI is the number of octets of the k-th Upper 
Layer PDU, or the last segment of it, in the current RLC data block. 



There is at least one Upper Layer PDU following the k-th Upper Layer 
PDU in the current RLC data block. 

There is no more than one Upper Layer PDU following the k-th Upper 
Layer PDU in the current RLC data block. 



r' LI: value =0 



k-th LI: 

0< value <75 (EGPRS) 
0< value <1 04 (TCH) 
(k>1 integer) 



The last Upper Layer PDU of the previous in sequence RLC data 
block ends at the boundary of that RLC data block and it has no LI in 
the header of that RLC data block. 

The k-th LI contains the number of octets of the (k-1)-th Upper Layer 
PDU in the current RLC data block. 



There is at least one Upper Layer PDU following the (k-1)-th Upper 
Layer PDU in the current RLC data block. 

There is no more than one Upper Layer PDU following the (k-1)-th 
Upper Layer PDU in the current RLC data block. 



k-thLI:value=127 



The octets between the end of the Upper Layer PDU indicated by the 
(k-1 )-th LI and the end of the current RLC data block are filling octets, 
or the octets contain part of an Upper Layer PDU that cannot be 
transmitted completely in the current RLC data block and will not be 
continued in the next in-sequence RLC data block. 



r'LI:value=0 



The previous RLC data block contains a Upper Layer PDU, or a part 
of it, that fills precisely the previous data block and for which there is 
no length indicator in that RLC data block. The current RLC data 
block contains a Upper Layer PDU that either fills the current RLC 
data block precisely or continues in the next RLC data bicok. 



r'LI:value=127 
{lu mode on\y) 



All octets of the RLC Data block contain filling information. 



No LI field present 



n.a. The Upper Layer PDU that starts with the current RLC data block 
either fills the current RLC data block precisely or continues in the 
following in-sequence RLC data block 



10.4.15 TLLI field 

The TLLI field contains a TLLI encoded as the contents of the TLLI information element defined in 3GPP TS 44.018. 

10.4.16 RLC data field 

The RLC data field contains octets from one or more Upper Layer PDUs. The RLC data field may contain parts of one 
or two Upper Layer PDUs and all of an arbitrary number of Upper Layer PDUs. The E bit, the M bit, and the Length 
Indicator delimit the RLC data field into Upper Layer PDUs. If the last Upper Layer PDU of a downlink TBF or an 
uplink RLC data block with CV = does not fill the entire RLC data field, an extension octet shall be used to indicate 
the number of valid RLC data octets. The remainder of the RLC data field shall be filled with filler octets with the value 
'OOlOlOir. Only the last RLC data block of a downlink TBF or an uplink RLC data block with CV = may contain 
filler octets. If an uplink TBF is continued after the RLC data block with CV = 0, the next Upper Layer PDU starts with 
the first octet of the RLC data field of the next in sequence RLC data block. 
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1 0.4.1 7 Control message contents field 

The Control message contents field shall contain exactly one segment from one RLC/MAC control message field (i.e. 
RLC/MAC control block). 

1 0.4.1 8 Resent Block Bit (RSB) 

The Resent Block Bit (RSB) indicates whether any of the RLC data blocks contained within the EGPRS radio block 
have been sent previously. The setting of this field is shown in table 10.4.18.1. 

Table 10.4.18.1 : Resent block bit 



bit 







All of the RLC data blocks contained within the EGPRS radio block 
are being transmitted for the first time 


1 


At least one RLC data block contained within the EGPRS radio 
block has been transmitted before 


NOTE: The use of this bit shall be reconsidered in future versions of the 
present document. 



10.4.19 PFI Indicator (PI) bit 

The PFI Indicator (PI) indicates the presence of the optional PFI field. The PI shall be ignored in lu mode. 

Table 10.4.19.1: PFI Indicator (PI) bit 



bit 


PFI Indicator (PI) bit 





PFI is not present 


1 


PFI is present if Tl field indicates presence of TLLI 



1 0.4.20 Packet Flow Identifier (PFI) field 

The PFI field contains a PFI value encoded as the contents of the PFI information element as defined in 
3GPPTS 44.018. 



1 1 Message functional definitions and contents 

This sub-clause defines the structure of the RLC/MAC control messages. These are non-standard L3 messages as 
defined in 3GPP TS 24.007. The formats for the messages are valid only for the PDCH. The format for RLC/MAC 
control messages for use on the CCCH are defined in 3GPP TS 44.018. 

The RLC/MAC control messages defined in this sub-clause may be used also on DBPSCH and SBPSCH in lu mode 
according to the requirements specified in 3GPP TS 44.160. A subset of these messages is used exclusively in lu mode. 
Messages belonging to that subset are labelled as "lu mode only" in this thechnical specification. 

A subset of the lu mode only messages is used exclusively on DBPSCH. These messages do not follow the general 
syntactical rules for the RLC/MAC control messages used on shared channels. The error handling defined for shared 
channels does not apply. Messages that may be sent from the network to the mobile station, and that belong to this 
subset, are classified as DBPSCH messages, see sub-clause 11.1.1. 

Each definition given in the present sub-clause includes: 

a brief description of the message direction and use; 

a CSN. 1 description of the message information elements and fields (see CSN. 1 Specification, Version 2.0). 
Definition of information elements may immediately follow the definition of the message. If the definition of an 
information element immediately follows the message definition, the information element name ends with 
'struct'. Otherwise the information element name ends with 'IE' and the definition of the information element is 
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defined in clause 12 or in 3GPP TS 44.018. The definition of a 'struct' is valid only within the table in which it is 
defined. No references shall be made to a 'struct' definition from outside of the table in which it is defined or 
from outside the present document. The definition of an information element is valid throughout clause 1 1 and 
sub-clause 12; 

a note specifying, where appropriate, conditions for information elements or fields with presence requirement C 
or O in the relevant message which together with other conditions specified in 3GPP TS 44.060 define when the 
information elements shall be included or not, what non-presence of such information elements or fields means, 
and - for lEs with presence requirement C - the static conditions for presence and/or non-presence of the 
information elements or fields (see 3GPP TS 24.007); 

a table follows which contains a definition for each field referenced in the message definition or in an 
information element struct immediately following the message definition. 

Bit fields within RLC/MAC messages shall have the highest numbered bit of the bit field in the highest numbered bit of 
the lowest number octet (see sub-clause 10. Ob. 3.1). The mapping of an 11 bit field is illustrated in figure 11.1. 



Octet N 
Octet N+1 
Octet N+2 
Octet N+3 

Figure 11.1: Field mapping within RLC/MAC messages 

The length of an RLC/MAC control messages is an integer number of RLC/MAC control blocks. Padding bits are 
necessary to fill the message up to the desired length. The padding bits may be the 'null' string. Otherwise, the padding 
bits starts with bit '0', followed by 'spare padding'. 

I < padding bits > ::= { null | < spare padding > ! < Ignore : 1 bit** = < no string > > } ; | 

The padding sequence used for 'spare padding' in the present document, see 3GPP TS 24.007, is a repetition of octet 
'OOlOlOir, starting on an octet boundary. 

11.1 Handling of erroneous protocol data 

This sub-clause specifies procedures for the handling of unknown and erroneous protocol data by the receiving entity. 

These error-handling procedures are mandatory for the mobile station. 

A message is defined to be syntactically incorrect if it violates rules of clauses 1 1 and 12, or if it contains at least one 
value defined as "reserved" in clauses 11 and 12. However, if the rules of clause 11 and 12 define a specific 
interpretation for a "reserved" value, the specified interpretation takes precedence and the considered field remains 
syntactically correct. 

Decoding a received message based on its CSN.l description yields the complete acceptance or rejection of the 
message. Error handling allows a message to be partially accepted even when some parts are erroneous. 

Error detection mechanisms are introduced to identify which parts of a message to be protected against which kinds of 
errors. 

11.1.1 Message classification 

The packet data channel (PDCH) is a shared resource, i.e. all mobile stations assigned resources on a PDCH may 
receive a message sent by the network. The message type is identified by the MESSAGE_TYPE field contained in each 
message. The message type is used for classification and determining the message syntax. 

Messages sent from the network to the mobile station on PDCH (A/Gb mode and lu mode) or DBPSCH {lu mode) are 
classified as either distribution messages or non-distribution messages. 
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Messages sent from the network to the mobile station exclusively on DBPSCH (lu mode) are classified as DBPSCH 

messages. 

11.1.1 .1 Distribution messages 

A distribution message is recognised by the most significant bit of the message type being set to bit '1'. The general 
format of a distribution message sent from the network to the mobile station is: 



< Distribution message > 


::= 


< MESSAGE TYPE : 


1 bit (5) > 


< Distribution contents 


> 


< padding bits > ; 





Any mobile stations may receive a distribution message. Depending on the protocol state of the mobile station, a 
distribution message shall be analysed as specified in sub-clauses 5, 6, 7, 8 and 9 of the present document. 

The 'Distribution contents' of a distribution message contains Page Mode information and any specific specific 
distribution information according to the syntax defined for the message type. The 'padding bits' of a distribution 
message can be reduced to the null string. 

The general format of the 'Distribution contents' is: 



< Distribution contents > ::= 

< PAGE_MODE : bit (2) > 

< specific distribution information > 



The encoding of the Page Mode information is defined in sub-clause 12.20. 

11.1.1 .2 Non-distribution messages 

A non-distribution message is recognised by the most significant bit of the message type being set to bit '0'. The general 
format of a message sent from the network to the mobile station is: 



< Non-distribution message > ::= 


< MESSAGE TYPE : bit (5) > 


< Distribution contents > 


< Address information > < Non-distribution contents > 


< padding bits > ; 



Any mobile station may receive a non-distribution message. 

The 'Distribution contents' of a non-distribution message contains Page Mode information and any specific distribution 
information according to the syntax defined for the message type. The general format of the 'Distribution contents' is 
defined in sub-clause 11.1.1.1. Depending on the protocol state of the mobile station, the 'Distribution contents' of a 
non-distribution message shall be analysed as specified in clauses 5 and 7 of the present document. 

The 'Address information' contained in a non-distribution message shall be analysed by a mobile station receiving the 
message. The 'Non-distribution contents' following the address information shall be ignored by any mobile station not 
identified by the address information. The allowed addressing options and the specific syntax of the 'Non-distribution 
contents' depend on the message type. The 'padding bits' of a non-distribution message can be reduced to the null string. 

11.1.1.2.1 Format of the address information 

The general format of the 'Address information' in a non-distribution message is: 



< Address information > ::= 




< Global TFI IE > | 


- see sub-clause 12. 10 


1 0<TLLI/G-RNTI>| 


- see sub-clause 12. 16 


110 < TQI > 1 - see 


sub-clause 12.17 


111 < Packet Request Reference IE > ; - see sub-clause 12.11 
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The description of a certain message type may specify a restricted set of addressing options being syntactically correct 
in the message. A message received with a disallowed addressing option shall be regarded as syntactically incorrect. 

11.1.1 .3 DBPSCH message {lu mode only) 

A DBPSCH message is sent exclusively on DBPSCH, from the network to the mobile station, in lu mode. The general 
format of such a message is: 



< DBPSCH message > ::= 

< DBPSCH message contents > 

< padding bits > ; 



The 'padding bits' of a DBPSCH message can be reduced to the null string. 
The general format of the 'DBPSCH message contents' is: 



< DBPSCH message contents > ::= 

< IV!ESSAGE_TYPE : bit (6) > 

< specific DBPSCH message information > 



11.1.2 Error detection mechanism 

The symbol '!' indicates an error branch. It acts as a separator (similar to the 'I' choice symbol) where the choice on the 
right of the '!' are to be considered as an 'error' branch. The symbol '!' allows partial analysis of data in a received 
message, with some parts of the message to be ignored due to it being syntactically incorrect. 

The description on the left of '!' defines the set of syntactically correct data and shall be recognised correctly. Otherwise, 
the data associated shall be rejected and the description within the error branch shall be used. 

The description within the error branch, on the right of '!', shall accept any syntactically incorrect data. Therefore, 
according to the error label the relevant error handling procedure shall be implemented. 

11.1.3 Error labels 

There are different categories of error labels introduced in clauses 1 1 and 12 of the present document. 

11.1.3.1 Generic error labels 

Generic error labels are defined for syntactical errors 'Unknown message type', 'Distribution part error', 'Address 
information part error' and 'Non-distribution part error'. 

The general format of a distribution message, including these error labels, is: 



< Distribution message > ::= 












< MESSAGE TYPE : 1 bit (5) > 










{ < Distribution contents > 












< padding bits > 












! < Distribution part error 


bit (*) - 


= < no string > 


>} 






! < Unknown message type : 


bit (6) -- 


= < no string > 


< Default downlinl< 


message 


content > > ; 



The general format of a non-distribution message, including these error labels, is: 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 189 ETSI TS 144 060 V6.28.0 (2010-03) 

< Non-distribution message > ::= 

< IVIESSAGE_TYPE : bit (5) > 
{ < Distribution contents > 

{ < Address information > 

{ < Non-distribution contents > 
< padding bits > 

! < Non-distribution part error : bit (*) = < no string > > } 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > } 
! < Unknown message type : bit (6) = < no string > < Default downlink message content > > ; 

The general format of a DBPSCH message, including these error labels, is: 

< DBPSCH message > ::= 

{ < DBPSCH message contents > 
< padding bits > 
! < DBPSCH message part error : bit (*) = < no string > > } ; 

These error labels allow ignoring a part of the message that is syntactically incorrect. Once an error is detected, the error 
branch is called. Except for the 'Unknown message type', the error branch is, followed by an unspecified bit string that 
expands to the end of the message. The corresponding data is ignored. In case of an 'Unknown message type', further 
treatment of the message is defined in sub-clause 1 1 . 1 .4. 1 . 

11.1.3.2 'Ignore' error label 

An 'Ignore' error label is used to ignore part of the message. The generic description is: 

< content > ! < Ignore : bit (*) = < no string > > - Ignore by indefinite length 

Or 

< content of fixed length n > ! < Ignore : bit (n) = < no string > > - Ignore by definite length 

An 'Ignore' error label shall be applied by the receiver of a downlink RLC/MAC control message when specified in the 
message description in clauses 1 1 and 12 of the present document. This error label allows ignoring a part of the message 
that is syntactically incorrect. Once the error is detected, the error branch 'Ignore' is called followed by a an unspecified 
bit string. 

When this error label is used with an indefinite length (bit (*) = < no string >), the unspecified bit string expands to the 
end of the message and the corresponding data is ignored. 

NOTE: If this error label is used with the indefinite length within a structure or delimited description (i.e. within 
{ } brackets), any description following the structure or delimited description must allow truncation, in 
order to be consistent with the CSN.l description of the message. 

When this error label is used with a definite length (bit (n) = < no string >), the unspecified bit string contains a defined 
number of bits. The corresponding data is ignored. 

11.1 .3.3 'Message escape' error label 

The 'Message escape' error label is used to provide an escape for, e.g. a future modification of the message syntax. The 
generic description is: 

< Content > ! < IVIessage escape : 1 bit (*) = < no string > > 

An 'Message escape' error label shall be applied by the receiver of a downlink RLC/MAC control message when 
specified in the message description in clauses 1 1 and 12 of the present document. The description on the left of the 
error branch needs to be correctly recognised. Otherwise, the error branch 'Message escape' is called and the remaining 
part of the message is ignored. 
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NOTE: Any description following a structure or delimited description (i.e. within { } brackets) including this 
error label must allow truncation. Otherwise, it is not consistent with the CSN. 1 description of the 
message. 

11.1.4 Error detection and order of precedence 

A mobile station shall detect and process errors in the order in which they are defined in this sub-clause of the present 
document. (E.g. a message, which is not compatible with the current protocol state AND is syntactically incorrect, shall 
be treated as if it is not compatible with the current protocol state.) 

At certain error events defined in this sub-clause, the PACKET TBF STATUS message shall be sent by the mobile 
station. In case of multiple error events, and, due to restrictions defined in sub-clauses 5, 6, 7, 8 and 9, the mobile 
station is not able to send a first status message until the occurrence of a subsequent event generating a second status 
message, the mobile station shall suppress the sending of the second and additional status messages until the first status 
message has been sent to the network. 

1 1 .1 .4.1 Unknown message type 

If a mobile station receives a message with message type either not defined or not implemented (generic error label: 
'Unknown message type'), the content of the bits representing the message type shall be ignored. 

The remaining part of the message shall be analysed according to the syntax defined as the 'Default downlink message 
content' in sub-clause 1 1 .2.0. 1 . The 'Default downlink message content' contains the Page Mode information. 
Depending on the protocol state of the mobile station, the Page Mode information shall be analysed as specified in 
clause 5 of the present document. 

11.1 .4.2 Message not compatible with current protocol state 

When a non-distribution message is received, which is not expected by the addressed receiver in its current protocol 
state, the mobile station shall follow the procedures that are described in sub-clauses 5, 6, 7, 8 and 9 of the present 
document. 

If no such reaction is specified, the mobile station shall ignore the message. If in packet transfer mode, the mobile 
station, which is identified by the address information shall return a status message (PACKET MOBILE TBF STATUS 
message) with TBF_CAUSE #4, "Message not compatible with current protocol state". 

Unexpected distribution messages are ignored. 

11.1 .4.3 Syntactically incorrect message 

When a message containing a syntactically incorrect data is received, depending on the error detection mechanisms that 
may be defined in the CSN. 1 description of the message, the message can be rejected or partially accepted. 

NOTE: The order, in which the error labels mentioned in this sub-clause are detected and processed, depends on 
the nesting of error labels defined by the description of each message type in sub-clause 11.2 and clause 
12. E.g. a message, which contains syntactically incorrect data in both the addressing information AND 
the non-distribution contents, is typically received with the error label 'Address information part error'. 

11.1 .4.3.1 Messages with error label: 'Distribution part error' 

For syntactically incorrect messages received with generic error label: 'Distribution part error', data corresponding to the 
description following the error label shall be recognised as erroneous data and be ignored. 

1 1 .1 .4.3.2 Messages with error label: 'Address information part error' 

For syntactically incorrect messages received with generic error label: 'Address information part error', data 
corresponding to the description following the error label shall be recognised as erroneous data and be ignored. The 
distribution contents preceding the error label may be analysed and treated as described in clause 5 and clause 7 of the 
present document. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 1 91 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

1 1 .1 .4.3.3 Messages with error label: 'Non-distribution part error' 

For syntactically incorrect messages received with generic error label: 'Non-distribution part error', data corresponding 
to the description following the error label shall be recognised as erroneous data and be ignored. 

The distribution contents preceding the error label may be analysed and treated as described in clause 5 and clause 7 of 
the present document. 

The address information preceding the error label shall be analysed. In packet transfer mode, the mobile station 
identified by the address information shall return a PACKET MOBILE TBF STATUS message with TBF_CAUSE #2 
"Syntactically incorrect message, non-distribution part error". 

11.1 .4.3.4 Messages with error label: 'Message escape' 

For syntactically incorrect messages with error label: 'Message escape', data corresponding to the description following 
the error label shall be recognised as erroneously received mandatory data and be rejected. 

The distribution contents preceding the error label may be analysed and treated as described in clause 5 of the present 
document. 

If the address information proceeds the error label and it is received correctly, it shall be analysed. In packet transfer 
mode, the mobile station identified by the address information shall return a PACKET MOBILE TBF STATUS 
message with TBF_CAUSE #3 "Syntactically incorrect message, message escape". 

1 1 .1 .4.3.5 Messages with error label: 'Ignore' 

For syntactically incorrect messages with error label: 'Ignore', data corresponding to the description following the error 
label shall be recognised as unnecessary data. If a syntactically incorrect message with the 'Ignore' error label is 
received, depending on the length of the unspecified bit string associated with the error label (sub-clause 11.1.3.2), the 
corresponding data shall be ignored. 

11.1 .4.3.6 Messages with error label: "DBPSCH message part error" 

For syntactically incorrect messages received with generic error label: 'DBPSCH message part error', data 
corresponding to the description following the error label shall be recognised as erroneous data and be ignored. 

11.1 .4.4 Syntactic error in truncated concatenation 

Truncated concatenation is sequences of components encapsulated by the { } brackets followed by the symbol '//'. The 
concatenation is any of the concatenations starting with null and up to any number of components. 

{oxbxo}// 

The above set is equivalent to: 

{oxbxo} or 

{ < a X b > } or 

{ < a > } or 

null 

Any syntactically incorrect component shall truncate the sequence. The correctly received components are accepted and 
the truncated components are ignored. 

NOTE: If the 'padding bits' at the end of a message are included within the concatenation, truncation requires the 
resulting concatenation to fit exactly with the received message length. Otherwise, it is a syntactical error, 
which may cause rejection of the complete message or part thereof. 
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11.1.4.5 (void) 



1 1 .2 RLC/MAC control messages 



Table 1 1.2.1 summarises the RLC/MAC control messages. For each control message, the message type shall be a fixed 
number of bits from the beginning of the message. 

Table 11.2.1: RLC/MAC control messages 



Uplink TBF establishment messages: 


Reference 


Packet Access Reject 


11.2.1 


Packet Channel Request 


11.2.5 


EGPRS Packet Channel Request 


11.2.5a 


Packet Queuing Notification 


11.2.15 


Packet Resource Request 


11.2.16 


Packet Uplink Assignment 


11.2.29 


Multiple TBF Uplink Assignment 


11.2.29a 


Additional MS Radio Access Capabilities 


11.2.32 


Downlink TBF establishment messages: 


Reference 


Packet DBPSCH Assignment 


11.2.5b 


Packet Downlink Assignment 


11.2.7 


Multiple TBF Downlink Assignment 


11.2.7a 
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TBF release messages: 


Reference 


Packet TBF Release 


11.2.26 


Paging messages: 


Reference 


Packet Paging Request 


11.2.10 


RLC messages: 


Reference 


Packet Downlink Ack/Nack 


11.2.6 


EGPRS Packet Downlink Ack/Nack 


11.2.6a 


Packet DBPSCH Downlink Ack/Nack 


11.2.6b 


Packet DBPSCH Downlink Ack/Nack Type 2 


11.2.6c 


MBMS Downlink Ack/Nack 


11.2.6d 


Packet Uplink Ack/Nack 


11.2.28 


Packet DBPSCH Uplink Ack/Nack 


11.2.28a 


Packet DBPSCH Uplink Ack/Nack Type 2 


11.2.28b 


System information messages: 


Reference 


Packet System Information Type 1 


11.2.18 


Packet System Information Type 2 


11.2.19 


Packet System Information Type 3 


11.2.20 


Packet System Information Type 3 bis 


11.2.21 


Packet System Information Type 3 ter 


11.2.21a 


Packet System Information Type 3 quater 


11.2.21b 


Packet System Information Type 5 


11.2.23 


Packet System Information Type 6 


11.2.23a 


Packet System Information Type 7 


11.2.23b 


Packet System Information Type 8 


11.2.24 


Packet System Information Type 13 


11.2.25 


Packet System Information Type 14 


1 1 .2.25a 


Pacl<et System Information Type 15 


11.2.25b 


Packet System Information Type 16 


1 1 .2.25c 


Miscellaneous messages: 


Reference 


Packet Control Acknowledgement 


11.2.2 


Packet Cell Change Continue 


11.2.2a 


Packet Cell Change Failure 


11.2.3 


Packet Cell Change Notification 


11.2.3a 


Packet Cell Change Order 


11.2.4 


Packet Downlink Dummy Control Block 


11.2.8 


Packet Uplink Dummy Control Block 


11.2.8b 


Packet Measurement Report 


11.2.9 


Packet IVIeasurement Order 


11.2.9b 


Packet Mobile TBF Status 


11.2.9c 


Packet Enhanced Measurement Report 


11.2.9d 


Packet Neighbour Cell Data 


11.2.9e 


Packet PDCH Release 


11.2.11 


Packet Polling Request 


11.2.12 


Packet Power Control/Timing Advance 


11.2.13 


Packet PRACH Parameters 


11.2.14 


Packet PSI Status 


11.2.17 


Packet Serving Cell Data 


11.2.17a 


Packet SI Status 


11.2.17b 


Packet Pause 


11.2.30a 


Packet Timeslot Reconfigure 


11.2.31 


Multiple TBF Timeslot Reconfigure 


11.2.31a 


Handover Access 


11.2.33 


Physical Information 


11.2.34 


Packet CS Request 


11.2.35 


Packet CS Command 


11.2.36 


Packet CS Release Indication 


11.2.37 


MBMS Service Request 


11.2.38 


MBMS Assignment (Non-distribution) 
MBMS Assignment (Distribution) 


11.2.39 
11.2.39a 


MBMS Neighbouring Cell Information 


11.2.40 


MBMS MS ID Assignment 


11.2.41 


Packet MBMS Announcement 


11.2.42 


PS Handover Command 


11.2.43 


PS Handover Access 


11.2.44 


Packet Physical Information 


11.2.45 
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1 1 .2.0 Message format 



All RLC/MAC control messages, with the exception of the PACKET CONTROL ACKNOWLEDGEMENT message 
in access burst format (11-bit and 8-bit contents), the HANDOVER ACCESS message in access burst format (8-bit 
content), the PS HANDOVER ACCESS message and the PACKET CHANNEL REQUEST message, follow the same 
non-standard format (see 3GPP TS 24.007). 



1 1 .2.0.1 Downlink RLC/MAC messages 

Downlink RLC/MAC control messages are received in RLC/MAC control block format. The different types of 
messages are distinguished by the MESSAGE_TYPE field. 



< Downlink RLC/MAC control message > ::= 


< MESSAGE TYPE 


bit (6) -- 


== 1 00001 > < Packet Access Reject message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 00001 > < Packet Cell Change Order message content > | 


< MESSAGE TYPE 


bit (6) = 


== 00010 > < Packet Downlink Assignment message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 0001 1 > < Packet Measurement Order message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 1 00010 > < Packet Paging Request message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 1 0001 1 > < Packet PDCH Release message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 00100 > < Packet Polling Request message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 00101 > < Packet Power Control/Timing Advance message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 1 001 00 > < Packet PRACH Parameters message content > | 


< MESSAGE TYPE 


bit (6) = 


== 001 1 > < Packet Queueing Notification message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 001 1 1 > < Packet Timeslot Reconfigure message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 01000 > < Packet TBF Release message content > | 


< MESSAGE TYPE 


bit (6) = 


== 01 001 >< Packet Uplink Ack/Nack message content > | - PACCH only 


< MESSAGE TYPE 


bit (6) = 


== 01010 > < Packet Uplink Assignment message content > | 


< MESSAGE TYPE 


bit (6) = 


== 0101 1 > < Packet Cell Change Continue message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 01 1 00 > < Packet Neighbour Cell Data message content > | 


< MESSAGE TYPE 


bit (6) -- 


==0 01101 > < Packet Serving Cell Data message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 01 1 1 > < Packet DBPSCH Assignment message content > | 


< MESSAGE TYPE 


bit (6) = 


==001111 > < Multiple TBF Downlink Assignment message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 10000 > < Multiple TBF Uplink Assignment message content > | 


< MESSAGE TYPE 


bit (6) = 


== 10001 > < Multiple TBF Timeslot Reconfigure message content > 


< MESSAGE TYPE 


bit (6) -- 


== 1001 1 >< MBMS MSJD Assignment message content > |- PACCH only 


< MESSAGE TYPE 


bit (6) = 


== 10100 > < MBMS Assignment (Non-distribution) message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 1 01 01 > < PS Handover Command message content > | - PACCH only 


< MESSAGE TYPE 


bit (6) -- 


==0 1 01 1 > < Packet Physical Information message content > | - PACCH only 


< MESSAGE TYPE 


bit (6) = 


== 1 00101 > < Packet Downlink Dummy Control Block message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 1 10001 > < PSI1 message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 1 10010 >< PSI2 message content > 


< MESSAGE TYPE 


bit (6) -- 


== 1 1001 1 > < PSI3 message content > 


< MESSAGE TYPE 


bit (6) -- 


==^ 10100 > < PSI3 bis message content > | 


< MESSAGE_TYPE 


bit (6) -- 


== 1 10101 > reserved | - this value was allocated in an earlier 






- version of the protocol and shall not be used 


< MESSAGE TYPE 


bit (6) -- 


== 1 1 01 1 > < PSI5 message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 1 10000 > < PSI6 message content > 


< MESSAGE TYPE 


bit (6) -- 


== 1 1 1000 > < PSI7 message content > 


< MESSAGE TYPE 


bit (6) -- 


== 1 1 1001 > < PSI8 message content > 


< MESSAGE TYPE 


bit (6) -- 


==^ 101 1 1 > < PSI13 message content > 


< MESSAGE TYPE 


bit (6) -- 


== 1 11010 >< PSI1 4 message content > 


< MESSAGE TYPE 


bit (6) -- 


==^ 1 1 1 00 > < PSI3 ter message content > | 


< MESSAGE TYPE 


bit (6) -- 


== 1 11101 > < PSI3 quater message content > | 


< MESSAGE TYPE 


bit (6) -- 


==^ 1 1 1 1 > < PSI1 5 message content > 


< MESSAGE TYPE 


bit (6) -- 


== 1 01000 > < PSI16 message content > 


< MESSAGE TYPE 


bit (6) -- 


== 1 00000 > < Packet Serving Cell SI message content > | 


< MESSAGE TYPE 


bit (6) = 


== 1 001 1 1 > < Packet CS Command message content > | 


< MESSAGE TYPE 


bit (6) = 


== 1 01001 > < Packet CS Release Indication message content > | 


< MESSAGE TYPE 


bit (6) -- 


==^ 01010 > < MBMS Assignment (Distribution) message content > | 


< MESSAGE TYPE 


bit (6) = 


== 1 01011 > < MBMS Neighbouring Cell Information message content >| 


< MESSAGE_TYPE 


bit (6) = 


== 1 01 1 00 > < Packet MBMS Announcement message content > 


! < Unknown message type : 


{ bit (6) = < no string > } < Default downlink message content > > ; 



NOTE: the MESSAGE_TYPE "010010" is reserved for the PHYSICAL INFORMATION message on DBPSCH 
only. 
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The 'Default downlink message contents' consists of the Page Mode information and an unspecified bit string that 
expands to the end of the message. 

< Default downlink message content > ::= 

< PAGE_MODE : bit (2) > 

bit (*) = < no string > ; 



The encoding of the Page Mode information is defined in sub-clause 12.20. 



1 1 .2.0.2 Uplink RLC/MAC messages 

Uplink RLC/MAC control messages, except those using the access burst formats, are received in the RLC/MAC control 
block format. The different types of messages are distinguished by the MESSAGE_TYPE field. 



Uplink RLC/IVIAC control message > 



< MESSAGE TYPE 


bit (6) = 


= 000000 > 


< MESSAGE TYPE 


bit (6) = 


= 000001 > 


< MESSAGE TYPE 


bit (6) = 


= 000010 > 


< MESSAGE TYPE 


bit (6) = 


= 00001 1 > 


< MESSAGE TYPE 


bit (6) = 


= 000100 > 


< MESSAGE TYPE 


bit (6) = 


= 001010 > 


< MESSAGE TYPE 


bit (6) = 


= 000101 > 


< MESSAGE TYPE 


bit (6) = 


= 0001 10 > 


< MESSAGE TYPE 


bit (6) = 


= 000111 > 


< MESSAGE TYPE 


bit (6) = 


= 001000 > 


< MESSAGE TYPE 


bit (6) = 


= 001001 > 


< MESSAGE TYPE 


bit (6) = 


= 001011 > 


< MESSAGE TYPE 


bit (6) = 


= 001 100 > 


< MESSAGE TYPE 


bit (6) = 


= 001101 > 


< MESSAGE TYPE 


bit (6) = 


= 001110> 


< MESSAGE TYPE 


bit (6) = 


= 001111 > 


< MESSAGE TYPE 


bit (6) = 


= 010000 > 



< Packet Cell Change Failure nnessage content > | 

< Packet Control Acknowledgement message content > | 

< Packet Downlink Ack/Nack message content > |-- PACCH only 

< Packet Uplink Dummy Control Block message content > | 

< Packet Measurement Report message content > | 

< Packet Enhanced Measurement Report message content > | 

< Packet Resource Request message content > | 

< Packet Mobile TBF Status message content > | 

< Packet PSI Status message content > | 

< EGPRS Packet Downlink Ack/Nack message content > | 

< Packet Pause message content > | 

< Additional MS Radio Access Capabilities message content > | 

< Packet Cell Change Notification message content > | 

< Packet SI Status message content > | 

< Packet CS Request message content > | 

< MBMS Service Request message content > | 

< MBMS Downlink Ack/Nack message content >; 



Messages using the access burst formats (1 1-bit and 8-bit formats) are defined in sub-clauses 1 1.2.2 1 1.2.5, 1 1.2.33, 
11.2.42 and 11.2.44. 



11 .2.1 Packet Access Reject 



This message is sent on the PCCCH or PACCH by the network to the mobile station to indicate that the network has 
rejected the MSs access request. This message may contain fields addressing more than one mobile station. 

Message type; PACKET ACCESS REJECT 

Direction: network to mobile station 

Classification: distribution message 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 1 96 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

Table 11.2.1.1: PACKET ACCESS REJECT information elements 

< Packet Access Reject message content > ::= 

< PAGE_MODE : bit (2) > 

< Reject : < Reject struct > > 

{ { 1 < Additional Reject: < Reject struct > > } ** 

{null |0 bit" =< no string > - Receiver compatible with earlier releases 
I 1 -- Additions in release 5 

{ 1 < lu mode Reject: < lu mode Reject struct > > } ** 
{ null I bit ** = < no string > -- Receiver compatible with earlier releases 
I 1 -- Additions in release 6 

{ 1 < A/Gb mode Reject: < A/Gb mode Reject struct > > } ** } 

< padding bits > } } // -- truncation at end of message allowed, bits '0' assumed 
! < Distribution part error : bit (*) = < no string > > ; 

< Reject struct > ::= 

{ < TLLI / G-RNTI : bit (32) > 

I 1 { < Packet Request Reference : < Packet Request Reference IE > > 

I 1 < Global TFI : < Global TFI IE > > } } 
{ I 1 < WAITJNDICATION : bit (8) > 

< WAIT _INDICATION_SIZE : bit (1) > } 
! < Ignore : bit (*) = <no string> > ; 

< lu mode Reject struct > ::= 

< G-RNTI_extension : bit (4) > 

{ -- all TBF requests for the MS identified by the G-RNTI in the corresponding Reject structare 

rejected 

I { 1 < RB Id : bit(5) > } " } ; -- TBF requests for these RB Ids are rejected 

< A/Gb mode Reject struct > ::= 

{ -- all TBF requests for the MS identified by the TLLI in the corresponding Reject struct are rejected 

I { 1 < PFI : bit (7) > } ** } ; -- TBF requests for these PFIs are rejected 
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Table 11.2.1.2: PACKET ACCESS REJECT information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Reject struct 

The mobile station shall only accept the first Reject struct addressed to it and ignore all other Reject structs. 

lu mode Reject struct 

For each occurrence of a G-RNTI in the TLLI / G-RNTI field of a Reject struct, a corresponding lu mode Reject struct 
shall be included in the message. The list of lu mode Reject structs shall address the lu mode mobile stations in the 
same order as the list of G-RNTI values in the Reject structs. 

A/Gb mode Reject struct 

For each occurrence of a TLLI in the TLLI / G-RNTI field of a Reject struct, a corresponding A/Gb mode Reject struct 
shall be included in the message. The list of A/Gb mode Reject structs shall address the A/Gb mode mobile stations in 
the same order as the list of TLLI values in the Reject structs. 

Packet Request Reference 

This information element shall be included if the PACKET ACCESS REJECT message is sent in response to a 
PACKET CHANNEL REQUEST message. This information element is defined in sub-clause 12. 11. 

TLLI / G-RNTI (32 bit field) 

This information field shall be included if the PACKET ACCESS REJECT message is sent in response to a PACKET 

RESOURCE REQUEST message or a Channel Request Description IE contained in a 

PACKET DOWNLINK ACK/NACK message. This information field is defined in sub-clause 12.16. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 

provide a unique identifier for contention resolution in lu-mode. 

For each occurrence of the TLLI / G-RNTI field in the Reject struct, the corresponding G-RNTI extension field shall be 
included in the lu mode reject struct in the same order as the list of G-RNTI values in the TLLI / G-RNTI field. 

Global TFI 

This information element contains the TFI of one of the mobile station's downlink TBFs or uplink TBFs. This field is 
defined in sub-clause 12.10. 

WAITJNDICATION (8 bit field) 

The Wait Indication field indicates the time the mobile station shall wait before attempting another channel request. 

This field is coded as the binary representation of the T3 172 timeout value in units of 20 ms or in units of seconds. The 

units are indicated in the WAIT_INDICATION_SIZE field. 

Range to 255. 

WAIT_INDICATION_SIZE (1 bit field) 

This field indicates the units of the WAITJNDICATION field. 

the WAITJNDICATION field is coded in units of s 

1 the WAITJNDICATION field is coded in units of 20 ms 

RB Id (5 bit field) 

This field contains the identifier of the radio bearer for which a TBF was requested. 

PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context. The PFI parameter is encoded as the contents 

of the PFI information element defined in 3GPP TS 44.018. 
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1 1 .2.2 Packet Control Acknowledgement 



This message is sent on the PACCH from the mobile station to the network. In lu mode, it is also sent on FACCH, 
SACCH and SDCCH from the mobile station to the network. The message is formatted either as an RLC/MAC control 
block using the PACCH block format defined in 3GPP TS 44.004 or as 4 identical access bursts using the PACCH short 
acknowledgement block format defined in 3GPP TS 44.004. If the CTRL_ACK_EXTENSION field is to be included 
(i.e. the MS is sending acknowledgement information for a RLC/MAC control message which it knows to have been 
segmented using extended RLC/MAC control message segmentation - see Table 1 1 .2.2.2) the message shall be 
formatted as an RLC/MAC control block. Otherwise, if sent as response to a Packet Polling Request message this latter 
message shall specify the format of the Packet Control Acknowledgement message. Otherwise the System Information 
parameter CONTROL_ACK_TYPE indicates which format the mobile station shall use. The order of bit transmission is 
defined in 3GPP TS 44.004. The numbering, assembling and field mapping conventions defined for RLC/MAC control 
blocks in sub-clause 10.0b shall apply. 

The RLC/MAC control block format is shown in table 1 1.2.2.1 and table 1 1.2.2.2. 

The access burst format is either 11 -bit or 8-bit and is coded as shown in table 11. 2. 2.1. The mobile station shall use the 
format indicated by the System Information parameter ACCESS_BURST_TYPE. The mobile station shall transmit the 
access burst four times, one time in each TDMA frame of the uplink radio block. 

Message type: PACKET CONTROL ACKNOWLEDGEMENT 

Direction: mobile station to network 

Table 11.2.2.1: PACKET CONTROL ACKNOWLEDGEMENT 

< Packet Control Acknowledgement message content > ::= ~ RLC/MAC control block format 

< TLLI/G-RNTI : bit (32) > 

< CTRL_ACK : bit (2) > 

{ null I bit** = < no string > - Receiver backward compatible with earlier version of the protocol 

I 1 - Release 5 additions 

{ |1 < TN_RRBP : bit (3) > } 
{ I 1 < G-RNTI extension : bit (4) > } 

{ null I bit** = < no string > - Receiver backward compatible with earlier version of the protocol 

I 1 - Release 6 additions 

{ I 1 < CTRL_ACK_EXTENSION : bit (9) > } 

< padding bits > } } ; 

< Packet Control Acknowledgement 1 1 bit message > ::= - 1 1-bit access burst format 

< l\/IESSAGE_TYPE : bit (9) == 1 1 1 1 1 100 1 > 

I { < MESSAGE_TYPE : bit (6) == 11 011 1 > 

< TN_RRBP : bit (3) > } 

< CTRL_ACK : bit (2) > ; 

< Packet Control Acknowledgement 8 bit message > ::= ~ 8-bit access burst format 

< l\/IESSAGE_TYPE : bit (6) == 01 1 1 1 1 > 

I { < MESSAGE_TYPE : bit (3) == 000> 

< TN_RRBP : bit (3) > } 

< CTRL_ACK : bit (2) > ; 



Table 11.2.2.2: PACKET CONTROL ACKNOWLEDGEMENT 

TLLI/G-RNTI (32 bit field) 

This field contains the TLLI/G-RNTI of the mobile station. This field is encoded as defined in sub-clause 12.16. 
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CTRL_ACK (2 bit field) 

This field contains acknowledgement information for the group of RLC/MAC control blocks that make up an 
RLC/MAC control message. The mobile station shall set the CTRL_ACK field to indicate which segments of an 
RLC/MAC control message have been received by the time of transmission of the PACKET CONTROL 
ACKNOWLEDGEMENT message. 

This field can also be coded to contain the information if the mobile station is requesting the establishment of new TBF. 
This coding is allowed only when the message is sent in access burst format as a response to the 
PACKET UPLINK ACK/NACK message with Final Ack Indicator set to '1' and TBF Est is set to '1'. 

If the PACKET CONTROL ACKNOWLEDGEMENT message is being transmitted in response to a vaUd RRBP field 
received as part of an RLC/MAC block with Payload Type equal to '10', the CTRL_ACK field shall be set according to 
the following table; 

bit 
2 1 
in case the message is sent in access burst format, the same meaning as for the value '11' except that the mobile 

station is requesting new TBF. Otherwise the bit value '00' is reserved and shall not be sent. If received it shall be 

intepreted as bit value '01'. 

1 the MS received an RLC/MAC control block addressed to itself and with RBSN = 1, and did not receive an 

RLC/MAC control block with the same RTI value and RBSN = 0. 

1 the MS received an RLC/MAC control block addressed to itself and with RBSN = 0, and did not receive an 

RLC/MAC control block with the same RTI value and RBSN = 1. This value is sent irrespective of the value of 
the FS bit. 
1 1 the MS received two RLC/MAC blocks with the same RTI value, one with RBSN = and the other with 
RBSN= 1. 

If the PACKET CONTROL ACKNOWLEDGEMENT message is being transmitted in response to a valid RRBP field 
received as part of an RLC/MAC block with Payload Type not equal to '10', the CTRL_ACK field shall be set to the 
value 'ir in case the message is sent in normal burst format or in case the mobile station is not requesting new TBF. In 
case the message is sent in access burst format and the mobile station is requesting new TBF, the CTRL_ACK field 
shall be set to the value '00'. 

If the PACKET CONTROL ACKNOWLEDGEMENT message is being transmitted in response to a polling request in 
an IMMEDIATE ASSIGNMENT message received on CCCH, the CTRL_ACK field shall be set to the value '11'. 

If the mobile station receives an RLC/MAC block with Payload Type equal to '10' and RLC/MAC block with Payload 
Type not equal to '10' with different RRBP values such that they specify the same uplink block, the mobile station shall 
set the CTRL_ACK field according to the group of RLC/MAC control blocks that the RLC/MAC block with Payload 
Type equal to '10' belongs. 
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CTRL_ACK_EXTENSION (9 bit field) 

This field contains acknowledgement information for the group of up to nine RLC/MAC control blocks that make up an 
RLC/MAC control message sent using extended RLC/MAC control message segmentation. The mobile station shall set 
the CTRL_ACK_EXTENSION field to indicate which segments of an RLC/MAC control message addressed to itself 
have been received by the time of transmission of the PACKET CONTROL ACKNOWLEDGEMENT message. Bit at 
index n in the CTRL_ACK_EXTENSION field indicates whether RLC/MAC control block "10 - n" has been received. 
This bit shall be set to ' 1 ' if the corresponding RLC/MAC control block has been received and to '0' otherwise. When 
CTRL_ACK_EXTENSION field is present, the CTRL_ACK field shall be ignored. The CTRL_ACK_EXTENSION 
field shall be included only if the MS knows an RLC/MAC control message has been segmented using extended 
RLC/MAC control message segmentation (i.e. the MS has received at least one segment other than the first segment of 
an RLC/MAC control message segmented using extended RLC/MAC control message segmentation). The 
CTRL_ACK_EXTENSION field shall not be included if the MS has only received the first segment of an RLC/MAC 
control message and hence does not know whether extended RLC/MAC control message segmentation is used. 

bit 
98765432 1 

000000000 this value is reserved and shall not be sent. 

1 00000000 this value is reserved and shall not be sent. 

10 10 the MS received the 3"* and 5* segments (i.e. with RBSN = ' 1 ' and RBSNe = '001 ' and RBSN = 
'1' and RBSNe = 'Oil' respectively) of an RLC/MAC control message sent using a given RTI 
value and did not receive any other RLC/MAC control block(s) with other RBSN and RBSNe 
values having that same RTI value. 

111111111 the MS received all nine segments of an RLC/MAC control message. 

If the mobile station receives an RLC/MAC block with Payload Type equal to '10' and an RLC/MAC block with 
Payload Type not equal to '10' with different RRBP values such that they specify the same uplink block, the mobile 
station shall set the CTRL_ACK_EXTENSION field according to the group of RLC/MAC control blocks that the 
RLC/MAC block with Payload Type equal to '10' belongs. 

TN_RRBP (3 bit field) 

This field contains the timeslot number of the downlink PDCH on which the RRBP was received. The TN_RRBP field 

is coded as the binary representation of the timeslot number as defined in 3GPP TS 45.002. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 

provide a unique identifier in lu mode. 



1 1 .2.2a Packet Cell Change Continue 



This message is sent on the PACCH by the network to the mobile station to command the mobile station to continue the 
cell reselection procedure. 

Message type: PACKET CELL CHANGE CONTINUE 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11. 2.2a.1 : PACKET CELL CHANGE CONTINUE message content 

< Packet Cell Change Continue message content > ::= 
< PAGE_MODE : bit (2) > 

{ < GLOBAL_TFI : Global TFI IE > 
{ {0| 1 <ARFCN:bit{10)> 

< BSIC : bit (6) > 

< CONTAINERJD : bit (2) > } 
< padding bits > 

I < Non-distribution part error : bit (*) = < no string > > } 
I < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

Table 11.2.2a.2: PACKET CELL CHANGE CONTINUE information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

The ARFCN, BSIC and the CONTAINERJD parameters shall be included if the network has earlier sent neighbour 
cell system information for the cell within a set of PACKET NEIGHBOUR CELL DATA messages referred by the 
corresponding CONTAINER_ID value but without ARFCN and BSIC provided. Otherwise these parameters are 
optional. 

ARFCN (10 bit field) 

This field contains the BCCH frequency of the new cell candidate for re-selection. This field is encoded as the ARFCN 

defined in 3GPP TS 44.018. 

Range to 1023 

BSIC (6 bit field) 

This field contains the BSIC of the new cell candidate for re-selection. This field is encoded as the BSIC value defined 

in 3GPPTS 44.018. 

Range to 63 

CONTAINERJD (2 bit field) 

This field contains the identity of the neighbour cell system information container previously sent in the PACKET 

NEIGHBOUR CELL DATA message for the cell addressed by the ARFCN and the BSIC above. 

Range to 3 



1 1 .2.3 Packet Cell Change Failure 

This message is sent on the PACCH from the mobile station to the network to indicate that a commanded cell change 
order has failed. For a (3G) multi-RAT mobile station this may be a 3G Cell. 

Message type: PACKET CELL CHANGE FAILURE 

Direction: mobile station to network 
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Table 1 1 .2.3.1 : PACKET CELL CHANGE FAILURE message content 



< Packet Cell Change Failure message content > ::= 


< TLLI / G-RNTI : bit (32) > 




<ARFCN:bit{10)> 




< BSIC : bit (6) > 




< CAUSE : bit (4) > 




{ null 1 bit ** = < no string > 


Receiver compatible with earlier release 


1 ~ Additions in release 99 : 




{ 1 1 < UTRAN FDD Target cell 


< UTRAN FDD Target cell IE > > } 


{ 1 1 < UTRAN TDD Target cell 


< UTRAN TDD Target cell IE > > } 


{ null 1 bit ** = < no string > -- 


Receiver compatible with earlier release 


1 -- Additions in Rel-5 : 




{ 1 1 < G-RNTI extension : bit (4) > } 


< padding bits > } } ; 





Table 11.2.3.2: PACKET CELL CHANGE FAILURE information element details 



TLLI / G-RNTI (32 bit field) 

This field is defined in sub-clause 12.16. 

ARFCN (10 bit field) 

This field contains the BCH fi^equency of the new cell on which the failure occurred. This field is encoded as the 

ARFCN defined in 3GPP TS 44.018. 

Range to 1023 

If a 3G Cell is indicated, this field shall be sent with the value 0. 

BSIC (6 bit field) 

This field contains the BSIC of the BCH frequency of the new cell on which the failure occurred. This field is encoded 

as the BSIC value defined in 3GPP TS 44.018. 

Range to 63 

If a 3G Cell is indicated, this field shall be sent with the value 0. 

CAUSE (4 bit field) 

This field indicates the cause of the cell change order failure on the target cell. 

bit 

4321 

Frequency not implemented 

1 No response on target cell 

10 Immediate Assign Reject or Packet Access Reject on target cell 

11 On going CS connection 

10 PS Handover failure -others 

10 1 MS in GMM Standby state 

110 Forced to the Standby state 

All others Reserved for future use 

UTRAN FDD Target cell 

This information element contains the description of the UTRAN FDD Target cell. This information element is defined 
in sub-clause 12.31. 

UTRAN TDD Target cell 

This information element contains the description of the UTRAN TDD Target cell. This field is defined in sub-clause 
12.32. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier in lu mode. 



ETSI 
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1 1 .2.3a Packet Cell Change Notification 



This message is sent on the PACCH by the mobile station to the network to inform the network that the cell re-selection 
criteria are now fulfilled and that the mobile station has entered CCN mode. 

Message type: PACKET CELL CHANGE NOTIFICATION 

Direction: mobile station to network 

Table 11.2.3a.1: PACKET CELL CHANGE NOTIFICATION message content 

< Packet Cell Change Notification message content > ::= 

< Global TFI : < Global IF! IE > > 
{0< ARFCN :bit(10)> 

< BSIC : bit (6) > 

I 1 -- Extension in Rel-6 and an escape bit for future extensions of tlie message added: 

< 3G Target Cell : < 3G Target Cell Struct » } -- Re-seiection witli a 3G ceil as ttie preferred target ceil 
{ 0< BA_USED : bit > |1 < PSI3_CHANGE_MARK : bit(2) > } 

< PMO_USED : bit > 

< PCCN_SENDING :bit{1)> 

< CCN Measurement Report : < CCN Measurement Report struct > > 

{ null I bit** = < no string > -- Receiver compatible witli earlier release 
I 1 -- Addition in Rei-6 

{ I 1 < 3G_BA_USED : bit > } 

< 3G CCN Measurement Report : < 3G CCN IVIeasurement Report struct > > 

< padding bits > }; 

< CCN IVIeasurement Report struct > ::= 

< RXLEV_SERVING_CELL : bit (6) > 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

< NUMBER_OF_NC_MEASUREMENTS : bit (3) > 
{ < FREQUENCY_N : bit (6) > 

{ I 1 < BSIC_N : bit (6) > } 

< RXLEV_N : bit (6) > } * {val(NUMBER_OF_NC_MEASUREMENTS)) ; 

< 3G Target Cell Struct > ::= 

{ I 1 < FDD-ARFCN : bit (1 4) > -- 3G UTRAN FDD 

{ 1 1 < Bandwidth_FDD : bit (3) > } 

< SCRAMBLING_CODE : bit (9) > } 

{ I 1 < TDD-ARFCN : bit (1 4) > -- 3G UTRAN TDD 

{ I 1 < Bandwidth_TDD : bit (3) > } 

< Cell Parameter : bit (7) > 

< Sync Case : bit > } 

< REPORTING_QUANTITY : bit (6) > ; -- Measurement Report for 30 target cell 

< 3G CCN Measurement Report Struct > ::= -- Measurement Report for 3G neighbour cells 

< N_3G: bit (3) > 

{ < 3G_CELL_LISTJNDEX : bit (7) > 

< REPORTING_QUANTITY : bit (6) > } * (val(N_3G + 1 )) ; 



Table 11. 2.3a.2: PACKET CELL CHANGE NOTIFICATION information element details 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

ARFCN (10 bit field) 

This field contains the BCCH frequency of the proposed cell for re-selection. This field is encoded as the ARFCN 

defined in 3GPP TS 44.018. 

Range to 1023 
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BSIC (6 bit field) 

This field contains the BSIC of the proposed cell for re-selection. This field is encoded as the BSIC value defined in 

3GPPTS 44.018. 

Range to 63 

BA_USED(1 bit field) 
3G_BA_USED (1 bit field) 

PSI3_CHANGE_MARK (2 bit field) 

These fields shall be included and contain the value of the BA_IND, 3G_BA_IND and PSI3_CHANGE_MARK 
respectively in the messages defining the used GSM Neighbour Cell list. 

In case PBCCH exists, PSI3_CHANGE_MARK shall be used. 

In case PBCCH does not exist, BA_USED and 3G_BA_USED shall be used. 

PMO_USED(l bit field) 

This parameter shall contain the value of the PMO_IND in the PACKET CELL CHANGE ORDER or PACKET 
MEASUREMENT ORDER messages that has modified the used GSM Neighbour Cell list. If no such message has 
been received, PMO_USED shall be set to zero. 

CCN Measurement Report struct 

This struct is identical to the NC Measurement Report struct specified in the PACKET MEASUREMENT REPORT 
message with the exception that the NC_MODE parameter is not part of the struct. 

PCCN SENDING (1 bit field) 

This is the first sending of the Packet Cell Change Notification message; 

1 This is the second sending of the Packet Cell Change Notification message. 

This field is used by the network to know whether the mobile station has just started T3208 or whether the reception of 
this message was triggered by T3210 expiry. 

3G Target Cell struct 

For information regarding the REPORTING QUANTITY see below. Regarding the other parameters see sub-clause 
11. 2.4 -PACKET CELL CHANGE ORDER message. 

3G CCN Measurement Report struct 

Measurement reporting for 3G Cells is defined in 3GPP TS 45.008. 

3G_CELL_LIST_INDEX (7 bit field) 

This is the index of the i'th reported 3G neighbour cell in the 3G Neighbour Cell List. See sub-clause 5.6.3.1. 

REPORTING_QUANTITY (6 bit field) 

This is the reporting quantity for the serving and for the i'th reported 3G cell. The quantities are defined in 

3GPP TS 45.008 for the respective Radio Access Technology 



1 1 .2.4 Packet Cell Change Order 

This message is sent on the PCCCH or PACCH by the network to the mobile station to command the mobile station to 
leave the current cell and change to a new cell. For a (3G) multi-RAT mobile station the new cell may be a 3G Cell. 

Message type: PACKET CELL CHANGE ORDER 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.4.1 : PACKET CELL CHANGE ORDER message content 

< Packet Cell Change Order message content > ::= 

< PAGE_MODE : bit (2) > 

{ {0 <GlobalTFI :<GlobalTFI IE>> 
I 10 < TLLI / G-RNTI : bit (32) > } 
{0 

{ < IMMEDIATE_REL : bit > 

< GSM target cell: < GSIVI target cell struct » 

! < Non-distribution part error : bit (*) = < no string > > } 

|1 

{ 00 -- Message escape 

{ < IMMEDIATE_REL : bit > 

{ I 1 < UTRAN FDD Target cell: < UTRAN FDD Target cell IE > > } 
{ I 1 < UTRAN TDD Target cell: < UTRAN TDD Target cell IE > > } 
{ null I bit ** = < no string > -- Receiver compatible witli earlier release 
I 1 -- Additions in Rel-5 : 

{ I 1 < G-RNTI extension : bit (4) > } 
< padding bits > } 
! < Non-distribution part error : bit (*) = < no string > > } 
I < Message escape : { 01 | 1 | 1 1 } bit {*) = <no string> > } } 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

< GSM target cell struct > ::= 

<ARFCN:bit(10)> 

< BSIC : bit (6) > 

< NC Measurement Parameters : < NC Measurement Parameters struct > > 
{ null I bit ** = < no string > - Receiver compatible with earlier release 
I 1 - Additions in release 98 : 

{ I 1 < LSA Parameters : < LSA Parameters IE » } 

{ null I bit ** = < no string > - Receiver compatible with earlier release 

I 1 - Additions in release 99 : 

< ENH Measurement parameters : < ENH Measurement parameters struct » 
{ null I bit ** = < no string > - Receiver compatible with earlier release 

I 1 ~ Additions in release R4 : 
<CCN_ACTIVE:bit{1)> 
{ I 1 < CONTAINERJD : bit (2) > } 

{ I 1 < CCN Support Description : < CCN Support Description struct » } 
{ null I bit ** = < no string > - Receiver compatible with earlier release 
I 1 - Additions in Rel-5 : 

{ I 1 < G-RNTI extension : bit (4) > } 

{ I 1 < lu Mode Neighbour Cell Parameters : { 1 < lu Mode Neighbour Cell params struct > } ** > 
} -Supplementary information for dual lu mode and A/Gb mode 

capable cells 

{ I 1 < NC lu MODE ONLY CAPABLE CELL LIST : NC lu Mode Only Cell List struct > } 
{ I 1 < GPRS 3G Additional Measurement Parameters Description 2 : 

< GPRS 3G Additional Measurement Parameters Description 2 struct »} 
{ null I bit ** = < no string > - Receiver compatible with earlier release 
I 1 - Additions in Rel-6 : 
< 3G_CCN_ACTIVE : bit (1) > 

< padding bits >}}}}}; 

< NC Measurement Parameters struct > ::= 

< NETWORK_CONTROL_ORDER : bit (2) > 
{ I 1 < NC_NON_DRX_PERIOD : bit (3) > 

< NC_REPORTING_PERIODJ : bit (3) > 

< NC_REPORTING_PERIOD_T : bit (3) > } 

{ I 1 < NC_FREQUENCY_LIST : NC Frequency list struct > } ; 

< NC Frequency list struct > ::= 

{ I 1 < NR_OF_REMOVED_FREQ : bit (5) > 

{ < REMOVED_FREQJNDEX : bit (6) > } * (1 + val(NR_OF_REMOVED_FREO)) } 
{ 1 < List of added Frequency : < Add Frequency list struct > >} ** 0; 
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< Add Frequency list struct > ::= 

< START_FREQUENCY : bit (10) > 

< BSIC : bit (6) > 

{ I 1 < Cell selection params : < Cell Selection struct > > } 

< NR_OF_FREQUENCIES : bit (5) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit {val(FREQ_DIFF_LENGTH)) > 

< BSIC : bit (6) > 

{ I 1 < Cell selection params : < Cell Selection struct > > } } * (val(NR_OF_FREQUENCIES)) ; 

< Cell Selection struct > ::= 

< CELL_BAR_ACCESS_2 : bit (1) > 

< EXC_ACC : bit > 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

{ I 1 < GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_MAX_CCH : bit (5) > } 
{ I 1 < GPRS_TEMPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TIME : bit (5) > } 

{ I 1 < GPRS_RESELECT_OFFSET : bit (5) > } 

{ I 1 < HCS params : < HCS struct > > } 

{ I 1 < SI13_PBCCH_L0CATI0N : < SI13_PBCCH_L0CATI0N struct > > } ; 

< SI13_PBCCH_L0CATI0N struct > ::= 

{ < SI13_L0CATI0N : bit (1) > 
I 1 < PBCCH_LOCATION : bit (2) > 

< PSI1_REPEAT_PERI0D : bit (4) > } ; 

< HCS struct > ::= 

< PRIORITY_CLASS : bit (3) > 

< HCS_THR : bit (5) > ; 

< ENH Measurement parameters struct > :: = 

{ < BAJND : bit >< 3G_BAJND : bit > | 1 < PSI3_CHANGE_MARK : bit{2) > } 

< PMOJND : bit > 

< REPORT_TYPE : bit > 

< REPORTING_RATE : bit > 

< INVALID_BSIC_REPORTING : bit > 

{ I 1 < 3G Neighbour Cell Description : < 3G Neighbour Cell Description struct » } 

{ I 1 < GPRS REP PRIORITY Description : < GPRS REP PRIORITY Description struct » } 

{ I 1 < GPRS MEASUREMENT Parameters Description : 

< GPRS IVIEASUREMENT PARAMETERS Description struct » } 
{ I 1 < GPRS 3G MEASUREMENT Parameters Description : 

< GPRS 3G MEASUREMENT PARAMETERS Description struct » } ; 

< 3G Neighbour Cell Description struct > ::= 

{ I 1 < lndex_Start_3G : bit (7) > } 

{ I 1 < AbsoluteJndex_Start_EMR : bit (7) > } 

{ I 1 < UTRAN FDD Description : < UTRAN FDD Description struct » } 

{ I 1 < UTRAN TDD Description : < UTRAN TDD Description struct » } 

{ I 1 < REMOVED_3GCELL_Description : < REMOVED_3GCELL_Description struct » } ; 

< REMOVED_3GCELL_Description struct > ::= 

< N1 : bit (2) > 

{ < N2 : bit (5) > 

{ < REM0VED_3GCELLJNDEX : bit (7) > 

< 3G_CELL_DIFF_LENGTH : bit (3) > 

< 3GCELL_DIFF : bit (val{3G_CELL_DIFF_LENGTH)) > 
}*{1+val{N2)) 

}*(1+val(N1)) ; 

< UTRAN FDD Description struct > ::= 

{ I 1 < Bandwidth_FDD : bit (3) > } 

{ 1 < Repeated UTRAN FDD Neighbour Cells : < Repeated UTRAN FDD Neighbour Cells struct » } ** ; 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 207 ETSI TS 144 060 V6.28.0 (2010-03) 

< Repeated UTRAN FDD Neighbour Cells struct > ::= 

< FDD-ARFCN : bit (1 4) > -- The value '1 ' was used in an earlier 

- version of the protocol and shall not be used. 

< FDDJndicO : bit > 

< NR_OF_FDD_CELLS : bit (5) > 

< FDD_CELLJNFORMATION Field : bit{p{NR_OF_FDD_CELLS)) > ; 

-- p(x) defined in table 1 1 .2.9b.2.a/3GPP TS 44.060 

< UTRAN TDD Description struct > ::= 

{ I 1 < Bandwidth_TDD : bit (3) > } 

{ 1 < Repeated UTRAN TDD Neighbour Cells : < Repeated UTRAN TDD Neighbour Cells struct » } ** ; 

< Repeated UTRAN TDD Neighbour Cells struct > ::= 

< TDD-ARFCN : bit (1 4) > -- The value '1 ' was used in an earlier 

- version of the protocol and shall not be used. 

< TDDJndicO : bit > 

< NR_OF_TDD_CELLS : bit (5) > 

< TDD_CELLJNFORMATION Field : bit{q{NR_OF_TDD_CELLS)) > ; 

-- q(x) defined in table 1 1 .2.9b.2.b/3GPP TS 44.060. 

< GPRS REP PRIORITY Description struct > ::= 

< NumberCells : bit{7) > 

{ < REP_PRIORITY : bit > } * (val(Number_Cells)) ; 

< GPRS MEASUREMENT PARAMETERS Description struct > ::= 

{ I 1 < MULTIBAND_REPORTING : bit (2) > } 
{ I 1 < SERVING_BAND_REPORTING : bit (2) > } 

< SCALE_ORD : bit(2) > 

{ I 1 < 900_REPORTING_OFFSET : bit (3) > 

< 900_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 1800_REPORTING_OFFSET : bit (3) > 

< 1800_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 400_REPORTING_OFFSET : bit (3) > 

< 400_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 1900_REPORTING_OFFSET : bit (3) > 

< 1900_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 850_REPORTING_OFFSET : bit (3) > 

< 850_REPORTING__THRESHOLD : bit (3) > } ; 

< GPRS 3G MEASUREMENT PARAMETERS Description struct > ::= 

< QsearchP : bit (4) > 

< 3G_SEARCH_PRI0 : bit > 

{ I 1 < FDD_REP_QUANT : bit > -- FDD Parameters 

< FDD_MULTIRAT_REPORTING : bit (2) > } 

{ I 1 < FDD_REPORTING_OFFSET : bit (3) > 

< FDD_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < TDD_MULTIRAT_REPORTING : bit (2) > } -- TDD Parameters 

{ I 1 < TDD_REPORTING_OFFSET : bit (3) > 

< TDD_REPORTING_THRESHOLD : bit (3) > } ; 

< CCN Support Description struct > ::= 

< NumberCells : bit (7) > 

{ CCN_SUPPORTED : bit } * (val(Number_Cells)) ; 

< lu Mode Neighbour Cell Params struct > ::= 

{ I 1 < lu Mode Cell Selection Params : <lu Mode Cell Selection struct > > } 

< NR_OF_FREQUENCIES : bit (5) > 

{ I 1 < lu Mode Cell Selection Params : 

< lu Mode Cell Selection struct > > } * (val{NR_OF_FREQUENCIES)) ; 

< lu Mode Cell Selection struct > ::= 

< CELL BAR QUALIFY 3 : bit (2) > 

{ I 1 < SnSAIt PBCCH Location: < SI13 PBCCH Location struct > > } ; 
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< NC lu Mode Only Cell List struct > ::= 

{ 1 < List of added cells : < Add lu Mode Only Cell List struct > >} ** 0; 

< Add lu Mode Only Cell List struct > ::= 

< START_FREQUENCY : bit (10) > 

< BSIC : bit (6) > 

{ I 1 < Cell selection params : < lu Mode Only Cell Selection struct > > } 

< NR_OF_FREQUENCIES : bit (5) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit {val(FREQ_DIFF_LENGTH)) > 

< BSIC : bit (6) > 

{ I 1 < Cell selection params : < lu Mode Only Cell Selection struct > > } } * (val{NR_OF_FREOUENCIES)) 

< lu Mode Only Cell Selection struct > ::= 

< CELL BAR QUALIFY 3 : bit (2) > 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

{ I 1 < GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_MAX_CCH : bit (5) > } 
{ I 1 < GPRS_TEMPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TIME : bit (5) > } 

{ I 1 < GPRS_RESELECT_OFFSET : bit (5) > } 

{ I 1 < HCS params : < HCS struct > > } 

{ I 1 < SI13Alt_PBCCH_L0CATI0N : < SI13_PBCCH_L0CATI0N struct > > } ; 

< GPRS 3G Additional Measurement Parameters Description 2 struct > ::= 

{ I 1 < FDD_REP0RTING_THRESH0LD_2 : bit (6) > } ; - FDD Parameters 

Table 11.2.4.2: PACKET CELL CHANGE ORDER information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

TLLI / G-RNTI (32 bit field) 

This field is defined in sub-clause 12.16. 

IMMEDIATE_REL (bit) 

This field indicates whether the MS shall immediately abort any operation in the old cell and move to the target cell 
(see sub-clause 8.4), or it shall not immediately abort operation in the old cell and follow the cell reselection procedure 
defined in sub-clause 5.5.1.1. This field is coded according to the following table: 

No immediate abort of operation in the old cell is required. 

1 Immediate abort of operation in the old cell is required. 

ARFCN (10 bit field) 

This field contains the BCCH frequency of the new cell. This field is encoded as the ARFCN defined in 

3GPPTS 44.018. 

Range to 1023 

BSIC (6 bit field) 

This field contains the BSIC of the new cell. This field is encoded as the BSIC value defined in 3GPP TS 44.018. 

Range to 63 

CCN_ACTIVE (1 bit field) 

This field indicates whether CCN is enabled towards GSM cells for the mobile station in the GSM cell addressed by 

ARFCN and BSIC. It is coded as follows: 

The broadcast CCN_ACTIVE parameter shall apply if available. Otherwise, CCN is disabled for the mobile station. 

1 CCN is enabled for the mobile station. 

CONTAINERJD (2 bit field) 

This optional parameters is included only if the network has earlier sent neighbour cell system information for the cell 

addressed by the ARFCN and the BSIC. For detailed element definition see sub-clause 1 1.2. 2. a. 
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The NC_Measurement_Parameters struct contains the NETWORK_CONTROL_ORDER and the optional 
parameters NC_NON_DRX_PERIOD, NC_REPORTING_PERIOD_I, NC_REPORTING_PERIOD_T and the 
NC_FREQUENCY LIST. These parameters shall apply in the target cell (see sub-clause 5.6.1) 

NETWORK_CONTROL_ORDER (2 bit field) 

The NETWORK_CONTROL_ORDER field is coded according to the following table (for definition of NCx see 

3GPPTS 45.008): 

bit 
2 1 
OONCO 

INCl 

1 0NC2 

1 1 RESET 

NC_NON_DRX_PERIOD (3 bit field) 
NC_REPORTING_PERIOD_I (3 bit field) 
NC_REPORTING_PERIOD_T (3 bit field) 
For detailed element definitions see the PSI5 message. 

NR_OF_REMOVED_FREQ (5 bit field) 

REMOVED_FREQ_INDEX (6 bit field) 

START_FREQUENCY (10 bit field) 

BSIC (6 bit field) 

For detailed element definitions, see the Packet Measurement Order message 

FREQ_DIFF_LENGTH (3 bit field) 

This field is required to calculate the number of bits to be used for the FREQUENCY_DIFF field in the current 

frequency group. The FREQ_DIFF_LENGTH value shall be different to 0. 

FREQUENCY_DIFF (val(FREQ_DIFF_LENGTH) bit field) 

Each FREQUENCY_DIFF parameter field specifies the difference in frequency to the next carrier to be defined. The F 
REQUENCY_DIFF parameter encodes a non negative integer in binary format (W). Each frequency following the start 
frequency (ARFCN(O)) and belonging to the Frequency List struct is then calculated by the formula ARFCN(n) = 
(ARFCN(n-l) + W(n) ) modulus 1024, n=l, . . ., val(NR_OF_FREQUENCIES). 

LSA Parameters 

This information element is defined in sub-clause 12.28. The 'LSA parameters IE' is optional. For detailed element 
definition, see the PSI3 message. 

ENH Measurement Parameters: 

For detailed element definitions see the Packet Measurement Order message 
(except that CDMA2000 Description struct does not exist in this message). 

UTRAN FDD Target cell 

This information element contains the description of the UTRAN FDD Target cell. This information element is defined 
in sub-clause 12.31. 

UTRAN TDD Target cell 

This information element contains the description of the UTRAN TDD Target cell. This information element is defined 
in sub-clause 12.32. 

GPRS MEASUREMENT PARAMETERS Description 

The fields of this Description are used for measurements, as defined in 3GPP TS 45.008. 
Any parameter present overwrites any old data held by the mobile station for this parameter. 

GPRS 3G MEASUREMENT PARAMETERS Description 

The fields of this Description are used for measurements, as defined in 3GPP TS 45.008. 
Any parameter present overwrites any old data held by the mobile station for this parameter. 
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GPRS REP PRIORITY Description 

REP_PRIORITY bit: 

Normal reporting priority 

1 High reporting priority 

The use of these bits is defined in sub-clause 5.6.3.5 and 3GPP TS 45.008. 

CCN Support Description 

CCN_SUPPORTED (1 bit field) 

This parameter is used for determining whether the mobile station shall enter CCN mode when re-selecting a GSM cell 

and CCN is enabled. The use of these bits is described in sub-clause°8.8.2a: 

Bit 

CCN is enabled towards the corresponding cell 

1 CCN is disabled towards the corresponding cell 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier in lu mode. 

lu Mode Neighbour Cell Parameters 

The lu mode Neighbour Cell Parameters shall only be included when the List of added Frequency struct is present. 
lu Mode Neighbour Cell Params Struct 

This struct presents supplementary information for lu mode capable cells. The struct assigns lu mode parameter values 
to the neighbouring cells defined by the message. The lu mode Neighbour Cell params struct values are assigned to the 
neighbouring cells in the same order they appear in the List of added Frequency struct. 

NC lu Mode Only Capable Cell List Parameters 

These parameters are used to add lu mode only capable cells to BA(GPRS) list. 
CELL BAR QUALIFY 3 (2 bit field) 

This information element is defined in 3GPP TS 44.018. 
GPRS 3G Additional Measurement Parameters Description 2 

The fields of this Description are used for measurements, as defined in 3GPP TS 45.008. 
Any parameter present overwrites any old data held by the mobile station for this parameter. 

3G_CCN_ACTIVE (1 bit field) 

This field indicates whether CCN is enabled towards 3G neighbouring cells. It is coded as follows: 

The broadcast 3G_CCN_ACTIVE parameter shall apply if available. Otherwise, CCN towards 3G cells is 
disabled in the cell. 

1 CCN towards 3G cells is enabled in the cell. 



1 1 .2.5 Packet Channel Request 



This message is sent in random mode on the PRACH using the PRACH uplink block format defined in 

3GPP TS 44.004. The order of bit transmission is defined in 3GPP TS 44.004. The numbering, assembling and field 

mapping conventions defined for RLC/MAC control blocks in sub-clause 10.0b shall apply. 

The message format is either 1 1-bit or 8-bit. The mobile station shall use the format indicated by the System 
Information parameter ACCESS_BURST_TYPE 

The 11-bit format is coded as shown in table 11. 2.5.1. 

The 8-bit format is coded as shown in table 1 1.2.5.2. 
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Table 1 1 .2.5.1 : PACKET CHANNEL REQUEST 1 1 bit message content 

< Packet channel request 1 1 bit message content > ::= 

< One Phase Access Request : < MultislotClass : bit (5) > 

< Priority : bit (2) > 

< RandomBits : bit (3) > > 

I < Short Access Request : 1 00 -- The value 100 was allocated In an earlier version of the protocol and shall not 
be used by the mobile station 

< NumberOfBlocks : bit (3) > 

< Priority : bit (2) > 

< RandomBits : bit (3) > > 

I < Two Phase Access Request : 110000 < Priority : bit (2) > 

< RandomBits : bit (3) > > 

< Page Response :1 10001 < RandomBits : bit (5) > > 

< Cell Update : 1 10010 < RandomBits : bit (5) > > 

< MM Procedure : 1 1 001 1 < RandomBits : bit (5) > > 

< Single Block Without TBF Establishment : 1 1 01 00 < RandomBits : bit (5) > > 

< One Phase Access Request in RLC unack mode : 1 10101 < RandomBits : bit (5) > > 

< Dedicated channel request : 1 101 10 < RandomBits : bit (5) > > 

< Emergency call : 1 1 01 1 1 < RandomBits : bit (5) > > 

< Single block MBMS access : 111 000 < RandomBits : bit (5) > > ; 



Table 11.2.5.2: PACKET CHANNEL REQUEST 8 bit message content 

< Pacl<et channel request 8 bit message content > ::= 

< One Phase Access Request : 1 < MultislotClass : bit (5) > 

< RandomBits : bit (2) > > 

I < Short Access Request :00 -- The value 00 was allocated In an earlier version of the protocol and shall not be 
used by the mobile station 

< NumberOfBlocks : bit (3) > 

< RandomBits : bit (3) > > 

< Two Phase Access Request : 01000 < RandomBits : bit (3) > > 

< Page Response :01001 < RandomBits : bit (3) > > 

< Cell Update : 01010 < RandomBits : bit (3) > > 

< MM Procedure : 0101 1 < RandomBits : bit (3) > > 

< Single Block Without TBF Establishment : 01 1 00 < RandomBits : bit (3) > > 

< One phase Access Request in RLC unack mode : 01 1010 < RandomBits : bit (2) > > 

< Dedicated channel request : 011011 < RandomBits : bit (2) > > 

< Emergency call : 01 1 1 00 < RandomBits : bit (2) > > 

< Single block MBMS access : 01 1 1 1 < RandomBits : bit (3) > >; 



Table 11.2.5.3: PACKET CHANNEL REQUEST details 



MultislotClass (5 bit field) 

This information field indicates the GPRS multislot class of the MS. The multislot class indicated by this field shall be 
the same as the GPRS multislot class indicated in the MS Radio Access Capability IE (see 3GPP TS 24.008). The 
coding is defined in the following table. 



bit 




54321 




00000 


multislot class 1 


00001 


multislot class 2 


11100 


multislot class 29 


other 


reserved values 
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Priority (2 bit field) 

This information field indicates the requested Radio Priority. This field is coded as shown in the following table. The 

8 bit format has a default Radio Priority of 4.bit 



bit 
2 1 
00 
01 
10 
1 1 



Radio Priority 1 (Highest priority) 

Radio Priority 2 

Radio Priority 3 

Radio Priority 4 (Lower priority) 



NumberOfBlocks (3 bit field) 

This information field indicates the number of blocks requested during a mobile originated Temporary Block Flow. 

This field is coded as shown in the following table: 



bit 
321 
000 
001 

1 1 1 



1 RLC data block 

2 RLC data blocks 

8 RLC data blocks 



RandoiiiBits (2 bit field or 3 bit field or 5 bit field) 
This is an unformatted field. 



1 1 .2.5a EGPRS Packet Channel Request 

This message may be sent by an EGPRS capable mobile station in a cell supporting EGPRS and where the 
EGPRS_PACKET_CHANNEL_REQUEST parameter indicates that this message shall be used. 

This message is sent in random mode on the PRACH using the PRACH uplink block format or on the RACH (see 
3GPP TS 44.018) using the RACH uplink / Uplink access burst block format defined in 3GPP TS 44.004. The order of 
bit transmission is defined in 3GPP TS 44.004. The numbering, assembling and field mapping conventions defined for 
RLC/MAC control blocks in sub-clause 10.0b shall apply. The message is coded in 1 1-bit format. 

The EGPRS capability is indicated using alternative training sequences (see 3GPP TS 45.002). 

Table 11. 2.5a.1: EGPRS PACKET CHANNEL REQUEST message content 



Training sequence 
(see 3GPP TS 45.002) 


bits 
11 1 


Packet Channel Access 


TSl 


< EGPRS Packet channel request 
message content > 


EGPRS with 8PSK capability in uplink 


TS2 


< EGPRS Packet channel request 
message content > 


EGPRS without 8PSK capability in uplink 
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Table 11. 2.5a.2: EGPRS PACKET CHANNEL REQUEST message content 



< EGPRS Packet channel request message content > ::= 

< One Phase Access Request : < MultlslotClass : bit (5) > 

< Priority : bit (2) > 

< RandomBits : bit (3) > > 

I < Short Access Request : 1 00 -- The value 100 was allocated In an earlier version of the protocol and shall not 
be used by the mobile station 

< NumberOfBlocks : bit (3) > 

< Priority : bit (2) > 

< RandomBits : bit (3) > > 

I < Two Phase Access Request : 1 1 0000 < Priority : bit (2) > 

< RandomBits : bit (3) > > 

I < Signalling : 110011 < RandomBits : bit (5) > > 

I < One phase Access Request In RLC unack mode : 1 1 01 01 < RandomBits : bit (5) > > 

I < Dedicated Channel Request : 1 101 10 < RandomBits : bit (5) > > 

I < Emergency call : 1 1 01 1 1 < RandomBits : bit (5) > >; 



Table 11. 2.5a.3: EGPRS PACKET CHANNEL REQUEST details 



MultlslotClass (5 bit field) 

This information field indicates the EGPRS multislot class of the MS. The multislot class indicated by this field shall 
be the same as the EGPRS multislot class indicated in the MS Radio Access Capability IE (see 3GPP TS 24.008). The 
coding is defined in the following table. 



bit 
54321 




00000 


multislot class 1 


00001 


multislot class 2 


11100 


multislot class 29 


other 


reserved values 



Priority (2 bit field) 

NumberOfBlocks (3 bit field) 

RandomBits (3 bit field) 

For the definition of these three last information fields see Packet Channel Request in sec. 1 1 .2.5. 



1 1 .2.5b Packet DBPSCH Assignment 



This message is sent on the PCCCH or the PACCH from the network to the mobile station in lu mode to assign one or 
more DBPSCH(s) or a SDCCH to the mobile station. 

Message type: PACKET DBPSCH ASSIGNMENT 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.5b.1 : PACKET DBPSCH ASSIGNMENT information elements 

< Packet DBPSCH Assignment message content > ::= 

< PAGE_MODE : bit (2) > 

{ I 1 <PERSISTENCE_LEVEL : bit (4) > * 4 } 
{ { < Global TFI : < Global TFI IE > > 
I 10 < G-RNTI : bit (32) > 

I 11 < Packet Request Reference : < Packet Request Reference IE » } 
{ -- Message escape 

{ < CHANNEL_DESCRIPTION : < Channel Description struct » 
{ I 1 < TIMING_ADVANCE_VALUE : bit (8) > } 

< NETWORK_RESPONSE_TIMES : < Network Response Times struct » 

< padding bits > -- truncation at end of message allowed, bits '0' assumed 
! < Non-distribution part error : bit (*) = < no string > > } 

! < Message escape : 1 bit (*) = <no string> > } 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

< Channel Description struct > ::= 

< CHANNEL_TYPE : bit (6) > 

< DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > 

{ -- Symmetric uplink and downlink timeslot allocation 

I 1 < UPLINK_TIMESLOT_ALLOCATION : bit (8) > } -- Asymmetric uplink and downlink timeslot allocation 
{ I 1 < USF : bit (3) > 

< USF_GRANULARITY : bit (1) > } 

< POWER_COMMAND : < Power Command struct > > 
{ I 1 < CHANNEL_MODE : bit (8) > } 

< TSC : bit (3) > 

{ < MAIO : bit (6) > 

< HSN : bit (6) > 

I 1 < ARFCN :bit(10)>} ; 

< Network Response Times struct > ::= 

{ -- Network's response times on SDCCH 

< RESPONSE_TIME_SDCCH : < Response Time SDCCH struct > > 
I 1 -- Network's reponse times on the assigned DBPSCH 

< RESPONSE_TIME_SACCH : < Response Time SACCH struct » -- Network's response time on SACCH 
{ -- Network's response time on FACCH/F 

-- I.e. between a request sent on TCH/F or FACCH/F and the corresponding response sent on FACCH/F 

< RESPONSETIMEFACCHF : < Response Time struct » 

I 1 < RESPONSE_TIME_FACCH_H : < Response Time struct »}}; -- Network's reponse time on FACCH/H 

< Response Time SDCCH struct > ::= 

< TRMIN_SDCCH : bit (1 ) > -- Network's minimum response time on SDCCH 

< TRESP_SDCCH: bit (1 ) >; -- Network's maximum response time on SDCCH 

< Response Time SACCH struct > ::= 

< TRMIN_SACCH : bit (1 ) > -- Network's minimum response time on SACCH 

< TRESP_SACCH: bit (1 ) >; - Network's maximum response time on SACCH 

< Response Time struct > ::= 

< TRMIN : bit (6) > 

< TRESP_MAC_DTM : bit (7) > 

< TRESP_MAC_Dedicated : bit (7) >; 

< Power Command struct> ::= -- Provides the power level to be used by the mobile station 

{ -- Normal power control 

I 1 < FPC_EPC : bit (1 ) > } -- Fast or Enhanced Power Control 

< POWER_LEVEL : bit (8) >; 

Table 11. 2.5b.2: PACKET DBPSCH ASSIGNMENT information elements details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PERSISTENCE_LEVEL (4 bit field for each Radio Priority 1 . . .4) 
This field is defined in sub-clause 12.14, PRACH Control Parameters. 

Global TFI 

This information element contains one of the mobile station's downlink or uplink TFIs. This field is defined in sub- 
clause 12.10. 
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G-RNTI (32 bit field) 

This field is defined in sub-clause 12.16. 

Packet_Request_Reference 

This information element is defined in sub-clause 12.1 1 

CHANNEL_TYPE (6 bit field) 

This field indicates the type of channel allocated to the mobile station on DBPSCH. The T bits indicate the subchannel 

number coded in binary. See 3GPP TS 45.002. 

bit 

654321 

T T SDCCH/4 + SACCH/C4 

1 T T T SDCCH/8 + SACCH/C8 

10 TCH/F + FACCH/F + SACCH/F 

1 1 T TCH/H + FACCH/H + SACCH/TH 

10 10 PDTCH/F + PACCH/F + SACCH/F 

All other values Reserved 

DOWNLINK_TIMESLOT_ALLOCATION (8 bit field) 

This field is coded as the Timeslot Allocation field defined in sub-clause 12.18. The uplink timeslot allocation is 
identical to the downlink timeslot allocation given in this field in case the UPLINK_TIMESLOT_ALLOCATION field 
is not included. 

NOTE: Multislot allocation is only possible with a CHANNEL_TYPE indicating TCH or PDTCH. 

UPLINK_TIMESLOT_ALLOCATION (8 bit field) 

This field is coded as the Timeslot Allocation field defined in sub-clause 12.18. It is included only in case of 

asymmetric timeslot allocation between downlink and uplink. 

NOTE: Multislot allocation is only possible with a CHANNEL_TYPE indicating TCH or PDTCH. 

CHANNEL_MODE (8 bit field) 

This field is coded as the mode part of the channel mode IE defined in 3GPP TS 44.018. It shall be included only in 

case a TCH is assigned to the mobile station. 

TSC (3 bit field) 

This field is the binary representation of the training sequence code, see 3GPP TS 45.002. 

Range: to 7. 

MAIO (6 bit field) 

This field is the binary representation of the mobile allocation index offset (MAIO), see 3GPP TS 45.002. 

Range: to 63. 

HSN (6 bit field) 

This field is the binary representation of the hopping sequence number, see 3GPP TS 45.002. 

Range: to 63. 

ARFCN (10 bit field) 

This field is the binary representation of the absolute radio frequency channel number (ARFCN) defined in 

3GPPTS 45.005. 

Range to 1023. 

TIMING_ADVANCE_VALUE (8 bit field) 
This field is defined in 3GPP TS 44.018. 
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TRMIN_SDCCH (1 bit field) 

This field indicates the minimum response time of the network on SDCCH, expressed as a number of TDMA frames. 

See 3GPPTS 44.160. 

Bit 

1 

32 

1 83 

TRESP_SDCCH (1 bit field) 

This field indicates the maximum response time of the network on SDCCH, expressed as a number of TDMA frames. 

See 3GPPTS 44.160. 

Bit 

1 

134 

1 185 

TRMIN_SACCH (1 bit field) 

This field indicates the minimum response time of the network on S ACCH, expressed as a number of TDMA frames. 

See 3GPPTS 44.160. 

Bit 

1 

25 

1 129 

TRESP_SACCH (1 bit field) 

This field indicates the maximum response time of the network on S ACCH, expressed as a number of TDMA frames. 

See 3GPPTS 44.160. 

Bit 

1 

129 

1 233 

TRMIN (6 bit field) 

This field indicates the minimum response time of the network, expressed as a number of TDMA frames. See 

3GPPTS 44.160. 

Bit 

654321 
000000 9 
000 1 10 

111111 72 

TRESP_MAC_DTM (7 bit field) 

TRESP_MAC_Dedicated (7 bit field) 

These fields indicate for a given MAC state the maximum response time of the network expressed as a number of 

TDMA frames. See 3GPP TS 44.160. 

Bit 

7654321 
0000000 14 
000 00 1 15 

1111111 141 
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FPC_EPC(1 bit field) 

This field indicates whether fast power control or enhanced power control (see 3GPP TS 45.008) shall be used. It is 

coded as follows: 

Bit 

1 

FPC in use 

1 EPC in use 

POWER_LEVEL (8 bit field) 

This field is coded as the binary representation of the "power control level", see 3GPP TS 45.005. This value shall be 

used by the mobile station according to 3GPP TS 45.008. 

Range: to 31 

USE (3 bit field) 

This field indicates the USF value assigned to the MS for all allocated timeslots (range to 7). This field is encoded as 

a binary representation of the USF value as defined in sub-clause 10.4.1. 

USF_GRANULARITY (1 bit field) 

This information field indicates the USF granularity to be applied by the mobile station on DBPSCH. 

the mobile station shall transmit one RLC/MAC block 

1 the mobile station shall transmit four consecutive RLC/MAC blocks 



1 1 .2.5c MPRACH Packet Channel Request 

This message is sent in random mode on the MPRACH using the PRACH uplink block format defined in 

3GPP TS 44.004. The order of bit transmission is defined in 3GPP TS 44.004. The numbering, assembling and field 

mapping conventions defined for RLC/MAC control blocks in sub-clause 10.0b shall apply. 

The message is coded as shown in table 11. 2. 5c. 1. 

Table 11.2.5c.1: MPRACH PACKET CHANNEL REQUEST message content 

< Packet channel request message content > ::= 

< Single block MBMS access: 0000 < RandomBlts: bit (7) > >; 

Table 11. 2.5C.3: MPRACH PACKET CHANNEL REQUEST details 

RandomBits (7 bit field) 
This is an unformatted field. 



1 1 .2.6 Packet Downlink Ack/Nack 

This message is sent on the PACCH from the mobile station to the network to indicate the status of downlink RLC data 
blocks received and to report the channel quality of the downlink. The mobile station may optionally initiate an uplink 
TBF. 

Message type: PACKET DOWNLINK ACK/NACK 

Direction: mobile station to network 
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Table 11.2.6.1: PACKET DOWNLINK ACK/NACK information elements 

< Packet Downlink Ack/Nack message content > ::= 

< DOWNLINK_TFI : bit (5) > 

< Ack/Nack Description : < Ack/Nack Description IE > > 

{ I 1 < Channel Request Description : < Channel Request Description IE > > } 

< Channel Quality Report : < Channel Quality Report struct > > 

{ null I bit** = <no string> -- Receiver backward compatible witli earlier version 

I 1 -- Additional contents for Release 1999 

{ I 1 < PFI : bit(7) > } 
{ null I bit** = < no string > - Receiver baci<ward compatible with earlier version 

I 1 -- Additions for REL-5 

{ I 1 < lu mode Channel Request Description : < lu mode Channel Request Description IE > > } 

{ I 1 < RB Id : bit (5) > } 

{ I 1 < Timeslot Number : bit (3) > } 

{ null I bit** = <no string> -- Receiver bacl<ward compatible with earlier version 

I 1 -- Additional contents for Release 6 

{ I 1 < Extended Channel Request Description : < Extended Channel Request Description IE > > } } 

< padding bits > } }; 



< Channel Quality Report struct > ::= 


< C VALUE : bit (6) > 




< RXQUAL : bit (3) > 




< SIGN VAR : bit (6) > 




{ 1 1 < 1 LEVEL TNO 


bit (4) > } 


{ 1 1 < 1 LEVEL TN1 


bit (4) > } 


{ 1 1 < 1 LEVEL TN2 


bit (4) > } 


{ 1 1 < 1 LEVEL TN3 


bit (4) > } 


{ 1 1 < 1 LEVEL TN4 


bit (4) > } 


{ 1 1 < 1 LEVEL TN5 


bit (4) > } 


{ 1 1 < 1 LEVEL TN6 


bit (4) > } 


{ 1 1 < 1 LEVEL TN7 


bit (4) > } 



Table 11.2.6.2: PACKET DOWNLINK ACK/NACK information element details 

DOWNLINK_TFI (5 bit field) 

This field contains the TFI of the mobile station's downlink TBF. This field is defined in sub-clause 12.15. On 

DBPSCH, this field equals the radio bearer identity of the radio bearer to which this message applies. 

Ack/Nack Description 

This information element is defined in sub-clause 12.3. 

Channel Request Description 

This information element is defined in sub-clause 12.7. If a PFI field is included in this message, it relates to the TBF 
request contained in the Channel Request Description IE. Neither this IE nor the PFI field shall be included if the 
Extended Channel Request Description IE is included. 

lu mode Channel Request Description 

This information element is defined in sub-clause 12.7a. 

Extended Channel Request Description 

This information element is defined in sub-clause 12.7b. This IE contains a request for one or more additional uplink 
TBFs and shall only be included if the mobile station and the network support multiple TBF procedures. If this IE is 
included, the Channel Request Description IE and PFI field in the message shall be omitted. 

C_VALUE (6 bit field) 

This field is encoded as the binary representation of the C value as specified in 3GPP TS 45.008. 

Range to 63 

RXQUAL (3 bit field) 

This field contains the RXQUAL parameter field calculated by the mobile station (see 3GPP TS 45.008). This field is 

encoded as defined in 3GPP TS 44.018. 

Range to 7 
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PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context relating to the resource request specified in the 
Channel Request Description IE. The PFI parameter is encoded as the contents of the PFI information element as 
defined in 3GPP TS 44.018. This field may be included if the network supports packet flow context procedures and if a 
Channel Request Description IE is included in the message. If this field is included but the Channel Request 
Description IE is omitted, this field shall be ignored. 

SIGN_VAR (6 bit field) 

This field contains the signal variance parameter SIGN_VAR calculated by the mobile station (see 3GPP TS 45.008). 

bit 

654321 

OdB^ to 0.25 dB^ 

1 >0.25 dB^ to 0.50 dB^ 

10 >0.50 dB^ to 0.75 dB^ 

111110 >15.50 dB^ to 15.75 dB^ 

111111 >15.75dB^ 

I_LEVEL_TNO (4 bit field) 

I_LEVEL_TN1 (4 bit field) 

I_LEVEL_TN2 (4 bit field) 

I_LEVEL_TN3 (4 bit field) 

I_LEVEL_TN4 (4 bit field) 

I_LEVEL_TN5 (4 bit field) 

I_LEVEL_TN6 (4 bit field) 

I_LEVEL_TN7 (4 bit field) 

These fields contain the I_LEVEL value measured on timeslots through 7, respectively. The I_LEVEL is defined in 

3GPP TS 45.008 and the coding of I_LEVEL is as follows; 

bit 

4321 

I_LEVEL 

1 I_LEVEL 1 

1110 I_LEVEL 14 

1111 I_LEVEL 15 

RB Id (5 bit field) 

This field contains the radio bearer identity of the mobile station's radio bearer for which the downlink data transfer on 
SFACCH is acknowledged. This field is not included when the PACKET DOWNLINK ACK/NACK messsage is sent 
on DBPSCH. This field is encoded as a binary number with range 0-3 1 

Timeslot Number (3 bit field) 

It contains the timeslot number of the timeslot on which the corresponding RRBP was received. This field shall be 
included if and only if the timeslot number of the PDTCH/SBPSCH on which the PACKET DOWNLINK ACK/NACK 
message is sent is different from the timeslot number of each of the timeslots assigned to this TBF in the direction of 
this TBF. This field is encoded as the binary representation of the timeslot number as defined in 3GPP TS 45.002. 



1 1 .2.6a EGPRS Packet Downlink Ack/Nack 

This message is sent on the PACCH from the mobile station to the network to indicate the status of downlink RLC data 
blocks received and to report the channel quality of the downlink. The mobile station may optionally initiate an uplink 
TBF or request a temporary suspension of the downlink TBF. 

Message type: EGPRS Packet Downlink Ack/Nack 

Direction: mobile station to network 
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Table 11.2.6a.1 : EGPRS PACKET DOWNLINK ACK/NACK information elements 

< EGPRS Packet Downlink Ack/Nack message content > ::= 

< DOWNLINK_TFI : bit (5) > 

< MS OUT OF MEMORY : bit(1 )> 

{ I 1 < EGPRS Channel Quality Report : < EGPRS Channel Quality Report IE > >} 
{ I 1 < Channel Request Description : >Channel Request Description IE > >} 
{ I 1 < PFI : bit(7) > } 
{ I 1 < EPD A/N Extension length : bit (6) > 

< bit (val{EPD A/N Extension length) + 1) 

& { < EPD A/N Extension Info > ! { bit** = <no string> }} > } 

< EGPRS Ack/Nack Description : < EGPRS Ack/Nack Description IE » 
<padding bits > } ; 

< EPD A/N Extension Info > ::= 

{ { - Rel-5 extension 

{ I 1 < lu mode Channel Request Description : < lu mode Channel Request Description IE > > } 
{ I 1 < RB Id : bit (5) > } 
{ I 1 < Timeslot Number : bit (3) > } } 
{ - Rel-6 extension 

{ I 1 < Extended Channel Request Description : < Extended Channel Request Description IE > > } } 
< spare bit >** } // ; -- Truncation may occur between released versions of the protocol 

- Tlie receiver shall assume the value zero of any truncated bits 



Table 11. 2.6a.2: EGPRS PACKET DOWNLINK ACK/NACK information element details 

DOWNLINK_TFI (5 bit field) 

This field contains the TFI of the mobile station's downlink TBF. This field is defined in sub-clause 12.15. On 

DBPSCH, this field equals the radio bearer identity of the radio bearer to which this message applies. 

EGPRS Ack/Nack Description IE (L bit field) 

This information element is defined in sub-clause 12.3.1. The number of bits (L) available for Ack/Nack Description 
information element depends on the inclusion of channel quality reports and channel requests. L shall be set so that the 
entire EGPRS PACKET DOWNLINK ACK/NACK message evenly fits into an RLC/MAC control block. If a lower L 
covers the entire receive window, that L shall be used. 

MS OUT OF MEMORY (1 bit field) 

This field indicates that the MS has no more enough memory to perform Incremental Redundancy. 

The MS has enough memory 

1 The MS is running out of memory 

Channel Request Description IE 

This information element is defined in sub-clause 12.7. If a PFI field is included in this message, it relates to the TBF 
request contained in the Channel Request Description IE. Neither this IE nor the PFI field shall be included if the 
Extended Channel Request Description IE is included. 

lu mode Channel Request Description IE 

This information element is defined in sub-clause 12.7a. 

Extended Channel Request Description 

This information element is defined in sub-clause 12.7b. This IE contains a request for one or more additional uplink 
TBFs and shall only be included if the mobile station and the network support multiple TBF procedures. If this IE is 
included, the Channel Request Description IE and PFI field in the message shall be omitted. 

EGPRS Channel Quality Report IE 

This information element is defined in sub-clause 12.5.1. 

PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context relating to the resource request specified in the 
Channel Request Description IE. The PFI parameter is encoded as the contents of the PFI information element as 
defined in 3GPP TS 44.018. This field may be included if the network supports packet flow context procedures and if a 
Channel Request Description IE is included in the message. If this field is included but the Channel Request 
Description IE is omitted, this field shall be ignored. 
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RB Id (5 bit field) 

This field contains the radio bearer identity of the mobile station's radio bearer for which the downlink data transfer on 
SFACCH is acknowledged. This field is not included when the EGPRS PACKET DOWNLINK ACK/NACK message 
is sent on DBPSCH. This field is encoded as a binary number with range 0-3 1 . 

Timeslot Number (3 bit field) 

It contains the timeslot number of the timeslot on which the corresponding RRBP was received. This field shall be 
included if and only if the timeslot number of the PDTCH/SBPSCH on which the EGPRS PACKET DOWNLINK 
ACK/NACK message is sent is different from the timeslot number of each of the timeslots assigned to this TBF in the 
direction of this TBF. This field is encoded as the binary representation of the timeslot number as defined in 
3GPPTS 45.002. 



1 1 .2.6b Packet DBPSCH Downlink Ack/Nack 

This message is sent on FACCH, SACCH or SDCCH from the mobile station to the network to indicate the status of 
downlink RLC data blocks received. 

Message type: PACKET DBPSCH DOWNLINK ACK/NACK 

Direction: mobile station to network 

Table 11. 2.6b.1: PACKET DBPSCH DOWNLINK ACK/NACK information elements 

< Packet DBPSCH Downlink Ack/Nack message > ::= 

< MESSAGE_TYPE : bit (6) == 000010 > 

< RB Id : bit (5) > 

{0 -TCH TBF mode 

{0 -All data blocks acknowledged, no retransmission requested 
I 1 < STARTING_SEQUENCE_NUMBER : bit (8) > 

< RECEIVED_BLOCK_BITMAP : bit (128) > } 
I 1 -DCCH TBF mode 

{0 -All data blocks acknowledged, no retransmission requested 
I 1 < STARTING_SEQUENCE_NUMBER : bit (4) > 

< RECEIVED_BLOCK_BITMAP : bit (8) > } } 

<padding bits > ; 

Table 11. 2.6b.2: PACKET DBPSCH DOWNLINK ACK/NACK information element details 

RB Id (5 bit field) 

This field contains the radio bearer identity of the mobile station's radio bearer for which the downlink data transfer is 

acknowledged. This field is encoded as a binary number with range 0-3 1 . 

STARTING_SEQUENCE_NUMBER (8 or 4 bit field) 

The SSN contains the value of V(R) when this information element was transmitted. This field is encoded as the binary 

representation of V(R). 

Range to 255 (8 bit field) 

Range to 15 (4 bit field) 
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RECEIVE_BLOCK_BITMAP (RBB) (128 or 8 bit field) 

The RBB is a bitmap representing Block Sequence Numbers. The bitmap is indexed relative to SSN as follows: 

BSN = (SSN - bit_number) modulo 256, for bit_number = 1 to 128 (128 bit field). 
BSN = (SSN - bit_number) modulo 16, for bit_number = 1 to 8 (8 bit field). 

The BSN values represented range: 

from (SSN - 1) mod 256 to (SSN - 128) mod 256 (128 bit field) 
from (SSN - 1) mod 16 to (SSN - 8) mod 16 (8 bit field) 

The value of each bit represents the acknowledgement status of the RLC data block with: 

BSN = (SSN - bit_number) mod 256 (128 bit field) 
BSN = (SSN - bit_number) mod 16 (8 bit field), 

it is encoded as follows: 

Negative acknowledgement 

1 Positive acknowledgement 

Mapping of the bitmap is defined in 3GPP TS 44. 160. 



1 1 .2.6c Packet DBPSCH Downlink Ack/Nack Type 2 

This message shall only be used when FLO is used. It is sent on ADCH from the mobile station to the network to 
indicate the status of downlink RLC data blocks received. 

Message type: PACKET DBPSCH DOWNLINK ACK/NACK TYPE 2 

Direction: mobile station to network 

Table 11. 2.6C.1 : PACKET DBPSCH DOWNLINK ACK/NACK TYPE 2 information elements 

< Packet DBPSCH Downlink Ack/Nack Type 2 message > ::= 

< MESSAGE_TYPE : bit (6) == 00001 > -- The same message type as for Packet DBPSCH Downlink Ack/Nack is 

- used since these two messages are mutually exclusive 

< RB Id : bit (5) > 

< EGPRS Channel Quality Report : < EGPRS Cliannel Quality Report IE > > 
{0 -UDCHTBFmode 

{ -- All data blocks acknowledged, no retransmission requested 

I 1 < FLO Ack/Nack Description : < FLO Ack/Nack Description IE > > } 
I 1 -CDCHTBFmode 

{ -- All data blocks acknowledged, no retransmission requested 

I 1 < STARTING_SEQUENCE_NUMBER : bit (4) > 
< RECEIVED_BLOCK_BITMAP : bit (8) > } } 
<padding bits > ; 

Table 11.2.6c.2: PACKET DBPSCH DOWNLINK ACK/NACK TYPE 2 information element details 

RB Id (5 bit field) 

This field contains the radio bearer identity of the mobile station's radio bearer for which the downlink data transfer is 

acknowledged. This field is encoded as a binary number with range 0-3 1 . 

FLO Ack/Nack Description IE (x bit field) 

This information element is defined in sub-clause 12.3.2. 

STARTING_SEQUENCE_NUMBER (4 bit field) 

The SSN contains the value of V(R) when this information element was transmitted. This field is encoded as the binary 

representation of V(R). 

Range to 15 
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RECEIVE_BLOCK_BITMAP (RBB) (128 or 8 bit field) 

The RBB is a bitmap representing Block Sequence Numbers. The bitmap is indexed relative to SSN as follows: 

BSN = (SSN - bit_number) modulo 16, for bit_number = 1 to 8 (8 bit field). 

The BSN values represented range: 

from (SSN - 1) mod 16 to (SSN - 8) mod 16 (8 bit field) 

The value of each bit represents the acknowledgement status of the RLC data block with: 
BSN = (SSN - bit_number) mod 16 (8 bit field), 

it is encoded as follows: 

Negative acknowledgement 

1 Positive acknowledgement 

Mapping of the bitmap is defined in 3GPP TS 44.160. 



1 1 .2.6d MBMS Downlink Ack/Nack 

This message is sent on the PACCH from the mobile station to the network to indicate the status of downlink RLC data 
blocks received, to report neighbouring cell measurements and to notify the network of the release of the MS_ID on the 
mobile station side. 

Message type: MBMS Downlink Ack/Nack 

Direction: mobile station to network 

Table 11. 2.6d.1: MBMS DOWNLINK ACK/NACK information elements 

< MBMS Downlink Ack/Nack message content > ::= 

< DOWNLINK_TFI : bit (5) > 

< MBMS Neighbouring Cell Report : < MBMS Neighbouring Cell Report struct > > -- Neighbouring cell reporting 

< MSJD Release Indication : bit (1) > 

{ I 1 < Extension Bits : Extension Bits IE > } -- sub-clause 12.26 

{ < Ack/Nack Description : < Ack/Nack Description IE > > -- Ack/Nack information 
I 1 < MS_OUT_OF_MEMORY : bit (1) > 

< EGPRS Ack/Nack Description : < EGPRS Ack/Nack Description IE > > } 
<padding bits > ; 

< MBMS Neighbouring Cell Report struct > ::= 

{0 <BA_USED:bit(1)> 

I 1 < PSI3_CHANGE_MARK : bit (2) > } 

< Neighbouring Cell Report : < Neighbouring Cell Report struct > >; 

< Neighbouring Cell Report struct > ::= 

< RXLEV_SERVING_CELL : bit (6) > - Serving cell Rx level 

< RESEL_CRITERIA_FULFILLED : bit (1 ) > - If re-selection criteria are fulfilled, only the 

- corresponding neighbouring cell is reported 

< NUMBER_OF_NEIGHBOURING_CELL_MEASUREMENTS : bit (3) > 

{ < NCELL_LISTJNDEX_N : bit (7) > -- Neighbouring cells Rx levels 

{ I 1 < BSIC_N : bit (6) > } 

< RXLEV_N : bit (6) > 

< RESEL_PARAMS_ACQUIRED : bit (1) > 

{0 -No ptm parameters acquired for that session 

- in that cell 

I 1 < MBMS_PTM_CHANGE_MARK : bit (2) > } - Ptm parameters acquired for that session in 

- that cell 

} * val (NUMBER_OF_NEIGHBOURING CELL_MEASUREMENTS) ; 
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Table 11.2.6d.2: MBMS DOWNLINK ACK/NACK information element details 

DOWNLINK_TFI (5 bit field) 

This field contains the TFI identifying the mobile station sending this message (i.e. the concatenation of the MBMS 

Bearer ID and the MS_ID). 

MS_ID Release Indication (1 bit field) 

This field is used by the mobile station to notify the network of the release of the MS_ID, for the MBMS radio bearer 

the message relates to, on the mobile station side. 

The MS_ID is not released on the mobile station side 

1 The MS_ID is released on the mobile station side 

Extension Bits 

This information element, if present, shall be skipped over. Any information content shall be ignored by the network. 
This information element is defined in sub-clause 12.26. 

Ack/Nack Description IE 

This information element is defined in sub-clause 12.3. 

MS OUT OF MEMORY (1 bit field) 

This field indicates that the MS has no more enough memory to perform Incremental Redundancy. 

The MS has enough memory 

1 The MS is running out of memory 

EGPRS Ack/Nack Description IE (L bit field) 

This information element is defined in sub-clause 12.3.1. The number of bits (L) available for Ack/Nack Description 
information element may depend on the number of neighbouring cell measurements included (see sub-clause 9.1.8.2.1). 
L shall be set so that the entire MBMS DOWNLINK ACK/NACK message evenly fits into an RLC/MAC control 
block. If a lower L covers the entire receive window, that L shall be used. 

BA_USED(1 bit field) 

PSI3_CHANGE_MARK (2 bit field) 

These fields shall contain the value of B A_IND and PSI3_CHANGE_MARK respectively in the message defining the 

used Neighbour Cell List. 

In case PBCCH exists, PSI3_CHANGE_MARK shall be used. 
In case PBCCH does not exist, BA_USED shall be used. 

RXLEV_SERVING_CELL (6 bit field) 

This field contains the value of the RXLEV parameter for the serving cell calculated by the mobile station (see 3GPP 

TS 45.008). This field is encoded. as the binary representation of the RXLEV parameter value defined in 3GPP TS 

45.008. 

Range to 63. 

Neighbouring cell reporting 

The reporting of neighbouring cell measurement results is done in decreasing order of the corresponding cell re- 
selection ranking, as described in sub-clause 5.6.4. In case cell re-selection criteria are fulfilled, only the measurement 
results for the corresponding neighbouring cell are included and no other measurement results for any other 
neighbouring cell are included. 

RESEL_CRITERIA_FULFILLED (1 bit field) 

This field indicates whether cell re-selection criteria are fulfilled. 

Bit 

Cell re-selection criteria are not fulfilled 

1 . Cell re-selection criteria are fulfilled 
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NUMBER_OF_NEIGHBOURING_CELL_MEASUREMENTS (3 bit field) 

This field is encoded as the binary representation of the amount of neighbouring cells reported. 

Bit 

32 1 
000 

1015 
11x6 

NCELL_LIST_INDEX_N (7 bit field) 

This field contains the index of the GSM Neighbour Cell list, see sub-clause 5.6.3.2. As an exception, if PBCCH is not 
present in the cell and the MS has not acquired the complete GSM Neighbour Cell list from the BCCH messages, this 
field shall refer to the BA(BCCH) list. 

BSIC_N (6 bit field) 

This field indicates the BSIC of the frequency upon which the measurement was made. This field shall be included only 
for frequencies that refer to the BA(BCCH) list. The field is encoded as the BSIC value defined in 3GPP TS 44.018. 
Range to 63 

RXLEV_N (6 bit field) 

This field indicates the measured RXLEV of the frequency upon which the measurement was made (see 

3GPP TS 45.008). This field is encoded as the RXLEV value defined in 3GPP TS 44.018. 

Range to 63 

RESEL_PARAMS_ACQUIRED (1 bit field) 

This field indicates whether the mobile station has received the re-selection parameters for the reported neighbouring 

cell. 

Bit 

No re-selection parameters received for this neighbouring cell 

1 Re-selection parameters received for this neighbouring cell 

MBMS_PTM_CHANGE_MARK (2 bit field) 

This field shall contain the value of the MBMS_PTM_CHANGE_MARK field in the latest MBMS NEIGHBOURING 
CELL INFORMATION message received by the mobile station for that MBMS session and that reported neighbouring 
cell. If no such MBMS_PTM_CHANGE_MARK is available, it shall not be included in the MBMS DOWNLINK 
ACK/NACK message. 



1 1 .2.7 Packet Downlink Assignment 



This message is sent on the PCCCH or PACCH by the network to the mobile station to assign downlink resources to the 
mobile station. 

A mobile allocation or reference frequency list received as part of this assignment message shall be valid until a new 
assignment is received or each TBF of the MS are terminated. 

Message type: PACKET DOWNLINK ASSIGNMENT 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.7.1 : PACKET DOWNLINK ASSIGNMENT information elements 

< Packet Downlink Assignment message content > ::= 
< PAGE_MODE : bit (2) > 
{ I 1 <PERSISTENCE_LEVEL : bit (4) > * 4 } 
{ {0 <GlobalTFI :<GlobalTFI IE>> 
I 10 < TLLI/ G-RNTI : bit (32) > } 
{ -- Message escape 
{ < MAC_MODE : bit (2) > 
<RLC_M0DE:bit(1)> 

< CONTROL_ACK : bit (1 ) > 

< TIMESLOT_ALLOCATION : bit (8) > 

< Packet Timing Advance : < Packet Timing Advance IE > > 
{ I 1 < PO : bit (4) > 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 
<PR_M0DE:bit(1)>} 

{ { I 1 < Frequency Parameters : < Frequency Parameters IE > > } 
{ I 1 < DOWNLINK_TFLASSIGNMENT : bit (5) > } 
{ I 1 < Power Control Parameters : < Power Control Parameters IE > > } 
{ I 1 < TBF Starting Time : < Starting Frame Number Description IE > > } 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 
{ null I bit** = <no string> -- Receiver backward compatible with earlier version 

1 1 -- Additional contents for Release 1999 

{ I 1 < EGPRS Window Size : < EGPRS Window Size IE » 

< LINK_QUALITY_IVIEASUREMENT_MODE : bit (2) > 

{ I 1 < BEP_PERI0D2 : bit(4) > }} 
{ I 1 <Packet Extended Timing Advance : bit {2)> } 
{ I 1 < COMPACT reduced IVIA : < COMPACT reduced MA IE » } 
{ null I bit** = < no string > -- Receiver backward compatible with earlier version 

1 1 -- Additions for REL-5 

{ I 1 < RB Id : bit (5) > 

{ I 1 < G-RNTI extension : bit (4) > } 
{ I 1 < Uplink Control Timeslot : bit (3) > } 
{0| 1 <HFN_LSB:bit(1)>}} 
{ null I bit** = < no string > - Receiver backward compatible with earlier version 
I 1 -- Additions for REL-6 

{ I 1 < PFI : bit (7) > } 
< padding bits >}}}}// -- truncation at end of message allowed, bits V assumed 

I < Non-distribution part error : bit (*) = < no string > > } 
! < Message escape : 1 bit (*) = <no string> > } 
! < Address information part error : bit (*) = < no string > > } 
I < Distribution part error : bit (*) = < no string > > ; 



Table 11.2.7.2: PACKET DOWNLINK ASSIGNMENT information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PERSISTENCE_LEVEL (4 bit field for each Radio Priority 1 . . .4) 
This field is defined in sub-clause 12.14, PRACH Control Parameters. 

Global TFI 

This information element contains the TFI of one of the mobile station's downlink TBFs or uplink TBFs. This field is 
defined in sub-clause 12.10. 

TLLI/ G-RNTI (32 bit field) 

This field is defined in sub-clause 12.16. 
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MAC_MODE (2 bit field) 

This information field was used in an earlier version of the protocol to indicate the medium access method to be used 
during an uplink TBF. For backward compatibility reasons, if there is an ongoing uplink TBF using the extended 
dynamic allocation, the network shall set the value of this field to 'extended dynamic allocation'. Otherwise, the value 
shall be set to 'dynamic allocation'. The mobile station shall ignore this field. 

bit 
2 1 

Dynamic Allocation 

1 Extended Dynamic Allocation 

1 Reserved — The value '10' was allocated in an earlier version of the protocol and shall not be used. 
1 1 Reserved — The value '11 ' was allocated in an earlier version of the protocol and shall not be used. 

RLC_MODE(l bit field) 

This field indicates the RLC mode of the requested TBF. 

RLC acknowledged mode 

1 RLC unacknowledged mode 

CONTROL_ACK (1 bit field) 

In A/Gb mode, this field shall be set to '1' if the network establishes a new downlink TBF for the mobile station whose 

timer T3192 is running. Otherwise this field shall be set to '0'. 

In lu mode, this field shall be set to '1' if the network wishes to instruct the mobile station to release a given TBF for 
which timer T3192 is running. The TBF to be released is identified by the TFI given in the 

DOWNLINK_TFI_ ASSIGNMENT field and has to be vaUd on the PACCH on which this message was sent. Otherwise 
this field shall be set to '0'. 

TIMESLOT_ALLOCATION (8 bit field) 
This field is defined in sub-clause 12.18. 

Packet Timing Advance 

This information element is defined in sub-clause 12.12. 

PO (4 bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

PR_MODE(l bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

Power Control Parameters 

This information element is defined in sub-clause 12.13. 

Frequency Parameters 

This information element is defined in sub-clause 12.8. 

DOWNLINK_TFI_ASSIGNMENT (5 bit field) 

This information element, if present, assigns the TFI to the mobile station to identify the downlink TBF described by 

this message. TFI is encoded as defined in sub-clause 12.15. 

TBF Starting Time 

The TBF Starting Time field contains a starting time that indicates the TDMA frame number during which the assigned 
TBF may start. If no downlink TBF is in progress, the mobile station need not monitor the TFI field of downlink RLC 
data blocks until the indicated TDMA frame number. After the indicated TDMA frame number, the mobile station shall 
operate as during a downlink TBF. If a downlink TBF is already in progress, the mobile station shall continue to use the 
parameters of the existing TBF until the TDMA frame number occurs. When the indicated TDMA frame number 
occurs, the mobile station shall immediately begin to use the new parameters assigned. This information element is 
defined in sub-clause 12.21. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 
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LINK_QUALITY_MEASUREMENT_MODE (2 bit field) 

This field determines the measurements to be included within the EGPRS Timeslot Link Quality Measurements IE. 

bit 
2 1 
The MS shall not report either interference measurements (y values) or per slot BEP measurements. 

1 The MS shall report available interference measurements (y values) for timeslots through 7. The y value is 

defined in 3GPP TS 45.008. No per slot mean BEP measurements shall be reported. 

1 The MS shall report mean BEP on each allocated time slot. The MS shall report the mean BEP measurement 

corresponding to the modulation for which it has received a larger number of blocks since the previous report. 
The MS shall make BEP measurements only on Radio Blocks intended for it. No interference measurements (y 
values) shall be reported. 

1 1 The MS shall report mean BEP on each allocated time slot. The MS shall report the mean BEP measurement 
corresponding to the modulation for which it has received a larger number of blocks since the previous report. 
The MS shall make BEP measurements only on Radio Blocks intended for it. In addition to mean BEP, the MS 
shall report interference measurements (y values) for no more than four time slots. The MS shall first report 
available interference measurements for time slots 0, 1,2, and 3; the MS shall next report available interference 
measurements for time slots 4, 5, 6, and 7; and the MS shall alternate between these two groups for subsequent 
reports. If any of the interference measurements are unavailable for reporting for reasons specified in 
3GPP TS 45.008, the MS shall substitute least-recently-reported and available interference measurements for 
time slots not already included in the report. 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 

COMPACT reduced MA 

This information element is defined in sub-clause 12.29. 

BEP_PERIOD2 (4 bit field) 

This field contains a constant which is used for filtering channel quality measurements in EGPRS. BEP_PERIOD2 

when present, or if not, when received in a previous message of the same TBF session, shall be used instead of 

BEP_PERIOD. For details see 3GPP TS 45.008. 

Range: to 15 

RB Id (5 bit field) 

This field is included in lu mode when a TBF is assigned. It contains the radio bearer identifier for the radio bearer 
using the assigned TBF. 
G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 

provide a unique identifier for contention resolution in lu-mode. 

Uplink Control Timeslot (3 bit field) 

This field contains the timeslot number of the timeslot where the PACCH for the MS is located. It is encoded as the 

binary representation of the timeslot number as defined in 3GPP TS 45.002. 

HFN_LSB(1 bit field) 

This field contains the least significant bit of the downlink HEN of the radio bearer for which the TBF is assigned. It is 

used in lu mode only. 

PFI (7 bit field) 

This field contains the PFI parameter identifying the Packet Flow Context related to the TBF identified in the 
DOWNLINK_TFI_ASSIGMENT field. The PFI parameter is encoded as the contents of the PFI information element 
defined in 3GPP TS 44.018. 
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1 1 .2.7.1 Special requirements in dual transfer mode for downlink TBF 

Special requirements apply when a downlink TBF is assigned to a mobile station in dual transfer mode or a mobile 
station about to enter dual transfer mode. 

If the mobile station has an RR connection to the network on a half -rate TCH, the network may assign a downlink TBF 
using the other sub-channel of the same timeslot for a half-rate PDCH (see 3GPP TS 45.002). In this case, the downlink 
assignment message shall be encoded with a timeslot allocation including the timeslot number for the half-rate TCH and 
the half-rate PDCH and only that timeslot number. The mobile station shall interpret this allocation as an allocation of a 
half-rate PDCH. 

1 1 .2.7a Multiple TBF Downlink Assignment 

This message is sent on the PACCH by the network to the mobile station to assign multiple downlink resources to the 
mobile station. 

A mobile allocation or reference frequency list received as part of this assignment message shall be valid until a new 
assignment is received or until all of the TBFs belonging to the MS are terminated. 

Message type: MULTIPLE TBF DOWNLINK ASSIGNMENT 

Direction: network to mobile station 

Classification: non-distribution message 

Table 11.2.7a.1: MULTIPLE TBF DOWNLINK ASSIGNMENT information elements 

< Multiple TBF Downlink Assignment message content > ::= 

< PAGE_MODE : bit (2) > 

{ I 1 <PERSISTENCE_LEVEL : bit (4) > * 4 } 
{ {0 <GlobalTFI :<GlobalTFI IE>> 

I 10 { < TLLI / G-RNTI : <TLLI / G-RNTI IE > >< G-RNTI extension : bit (4) > } } 
{ - Message escape 

{ < Packet Timing Advance : < Packet Timing Advance IE > > 
{ I 1 < PO : bit (4) > 

<PR_l\/IODE:bit(1)>} 
{ { I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

{ I 1 < Power Control Parameters : < Power Control Parameters IE > > } 
{ I 1 < TBF Starting Time : < Starting Frame Number Description IE > > } 
{ I 1 { |1 < EGPRS Window Size : < EGPRS Window Size IE > > } 

< LINK_QUALITY_MEASUREI\/IENT_MODE : bit (2) > 
{ I 1 < BEP_PERI0D2 : bit{4) > }} 
{ I 1 <Packet Extended Timing Advance : bit (2) > } 
{ I 1 < Uplink Control Timeslot : bit (3) > } 

{ 1 < Multiple Downlink TBF Assignment : < IVIultiple Downlink TBF Assignment struct > > } ** 
< padding bits > }} // - truncation at end of message allowed, bits V assumed 

! < Non-distribution part error : bit (*) = < no string > > } 
! < Message escape : 1 bit (*) = < no string > > } 
! < Address information part error : bit (*) = < no string > > } 
I < Distribution part error : bit (*) = < no string > > ; 

< Multiple Downlink TBF Assignment struct > ::= 

< TIMESLOT_ALLOCATION : bit (8) > 

{ 1 < Downlink TBF assignment : < Downlink TBF assignment struct > > } ** ; 

< Downlink TBF assignment struct > :: = 

{ < RB Id : bit (5) > 
I 1 < PFI : bit (7) > 

<RLC_M0DE:bit(1)>} 

< TFI Assignment : bit (5) > 

< CONTROL_ACK : bit (1) > 

{ I 1 < EGPRS Window Size : < EGPRS Window Size IE > > } 

{ I 1 < HFN_LSB : bit (1 ) > } ; - HFN_LSB field used in lu mode only 
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Table 11.2.7a.2: MULTIPLE TBF DOWNLINK ASSIGNMENT information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PERSISTENCE_LEVEL (4 bit field for each Radio Priority 1 . . .4) 
This field is defined in sub-clause 12.14, PRACH Control Parameters. 

Global TFI 

This information element identifies one of the mobile station's downlink or uplink TFIs. This field is defined in sub- 
clause 12.10. 

TLLI / G-RNTI 

This information element is defined in sub-clause 12.16. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier for contention resolution in lu-mode. 

CONTROL_ACK (1 bit field) 

This field shall be set to "1" if the network wishes to instruct the mobile station to release the given TBFs for which 
timer T3192 is running. The TBFs to be released are identified by the TFIs given in the TFI Assignment field and have 
to be valid on the PACCH on which this message was sent. Otherwise this field shall be set to "0". 

TIMESLOT_ALLOCATION (8 bit field) 

This field describes the timeslot(s) on which all TBFs described in this message are assigned resources. 

Uplink Control Timeslot (3 bit field) 

This field contains the timeslot number of the timeslot where the PACCH for the MS is located. It is encoded as the 

binary representation of the timeslot number as defined in 3GPP TS 45.002. 

Packet Timing Advance 

This information element is defined in sub-clause 12.12. 

PO (4 bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

PR_MODE(l bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

Power Control Parameters 

This information element is defined in sub-clause 12.13. 

Frequency Parameters 

This information element is defined in sub-clause 12.8. 

TFI Assignment (5 bit field) 

This information element assigns one (or more) TFI(s) to each TBF assigned to the mobile station in this message. This 

field is repeated for each TBF that is assigned in this message. TFI is encoded as defined in sub-clause 12.15. 

TBF Starting Time 

The TBF Starting Time field contains a starting time that indicates the TDMA frame number during which the assigned 
TBFs may start. If no downlink TBF is in progress, the mobile station need not monitor the TFI field of downlink RLC 
data blocks until the indicated TDMA frame number. After the indicated TDMA frame number, the mobile station shall 
operate as during a downlink TBF. If a downlink TBF is already in progress, the mobile station shall continue to use the 
parameters of the existing TBF until the TDMA frame number occurs. When the indicated TDMA frame number 
occurs, the mobile station shall immediately begin to use the new parameters assigned. This information element is 
defined in sub-clause 12.21. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 
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LINK_QUALITY_MEASUREMENT_MODE (2 bit field) 

This field determines the measurements to be included within the EGPRS Timeslot Link Quality Measurements IE. 

Bit 

2 1 

The MS shall not report either interference measurements (y values) or per slot BEP measurements. 

1 The MS shall report available interference measurements (y values) for timeslots through 7. The y value is 

defined in 3GPP TS 45.008. No per slot mean BEP measurements shall be reported. 

1 The MS shall report mean BEP on each allocated time slot. The MS shall report the mean BEP measurement 

corresponding to the modulation for which it has received a larger number of blocks since the previous report. The 
MS shall make BEP measurements only on Radio Blocks intended for it. No interference measurements (y values) 
shall be reported. 

1 1 The MS shall report mean BEP on each allocated time slot. The MS shall report the mean BEP measurement 

corresponding to the modulation for which it has received a larger number of blocks since the previous report. The 
MS shall make BEP measurements only on Radio Blocks intended for it. In addition to mean BEP, the MS shall 
report interference measurements (y values) for no more than four time slots. The MS shall first report available 
interference measurements for time slots 0, 1,2, and 3; the MS shall next report available interference 
measurements for time slots 4, 5, 6, and 7; and the MS shall alternate between these two groups for subsequent 
reports. If any of the interference measurements are unavailable for reporting for reasons specified in 
3GPP TS 45.008, the MS shall substitute least-recently-reported and available interference measurements for time 
slots not already included in the report. 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 

BEP_PERIOD2 (4 bit field) 

This field contains a constant which is used for filtering channel quality measurements in EGPRS. BEP_PERIOD2 

when present, or if not, when received in a previous message of the same TBF session, shall be used instead of 

BEP_PERIOD. For details see 3GPP TS 45.008. 

Range: to 15 

RB Id (5 bit field) 

This field contains the radio bearer identifier for the radio bearer using the assigned TBF. This provides the mapping of 

TFI to RB Id which is necessary to uniquely identify lu-mode data flows. 

PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context. The PFI parameter is encoded as the contents 

of the PFI information element as defined in 3GPP TS 44.018. 

RLC_MODE(l bit field) 

This field indicates the RLC mode of the assigned TBF. 

RLC acknowledged mode 

1 RLC unacknowledged mode 

HFN_LSB (1 bit field) (lu mode only) 

This field contains the least significant bit of the downlink HEN of the radio bearer for which the TBF is assigned. 



1 1 .2.8 Packet Downlink Dummy Control Block 

This message is sent on the PCCCH or PACCH by the network to the mobile station as a fill message with either of the 
optional parameters PAGE_MODE and PERSISTENCE_LEVEL or with no content. In lu mode, it is also sent on 
FACCH, SACCH and SDCCH. 

Message type: PACKET DOWNLINK DUMMY CONTROL BLOCK 

Direction: network to mobile station 
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Classification: distribution message 

Table 11.2.8.1: PACKET DOWNLINK DUMMY CONTROL BLOCK information elements 



< Packet Downlink Dummy Control Block message content > 

< PAGE_MODE : bit (2) > 

{ I 1 <PERSISTENCE_LEVEL : bit (4) > * 4 } 

< padding bits > 

! < Distribution part error : bit (*) = < no string > > ; 



Table 11.2.8.2: PACKET DOWNLINK DUMMY CONTROL BLOCK information element details 



PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PERSISTENCE_LEVEL (4 bit field for each Radio Priority 1 . . .4) 
This field is defined in sub-clause 12.14, PRACH Control Parameters. 



1 1 .2.8b Packet Uplink Dummy Control Block 



This message is sent on the PACCH from the mobile station to the network when the mobile station has no other block 
to transmit. In lu mode, it is also sent on FACCH, SACCH and SDCCH. 

Message type: PACKET UPLINK DUMMY CONTROL BLOCK 

Direction: mobile station to network 

Table 11.2.8b.1: PACKET UPLINK DUMMY CONTROL BLOCK information elements 



< Packet Uplink Dummy Control Block message content > ::= 


< TLLI / G-RNTI : bit (32) > 




{ null 1 bit ** = < no string > 


- Receiver compatible with earlier release 


M 


- Additions in Rel-5 : 


{ 1 1 < G-RNTI extension 


bit (4) > } 


< padding bits > } ; 





Table 11.2.8b.2: PACKET UPLINK DUMMY CONTROL BLOCK information element details 



TLLI / G-RNTI (32 bit field) 

This field contains the TLLI / G-RNTI of the mobile station. This field is encoded as defined in sub-clause 12.16. 



G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier in lu mode. 



1 1 .2.9 Packet Measurement Report 



This message is sent on the PACCH from the mobile station to the network to report measurement results. The message 
contains measurement results from the Network Control measurements. For a (3G) multi-RAT mobile station, report on 
3G cells may be included. 

Message type: PACKET MEASUREMENT REPORT 

Direction: mobile station to network 
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Table 11.2.9.1 : PACKET MEASUREMENT REPORT message content 

< Packet Measurement Report message content > ::= 

< TLLI / G-RNTI : bit (32) > 

{ I 1 < PSI5_CHANGE_MARK : bit (2) > } 

< NC Measurement Report : < NC IVIeasurement Report struct > > 

{ null I bit** = < no string > - Receiver compatible with earlier release 

1 1 -- Additions in release 99 : 

{ 1 1 { < BA_USED : bit >< 3G_BA_USED : bit > | 1 < PSI3_CHANGE_MARK : bit(2) > } 

< PMO_USED : bit > } 

{ I 1 < 3G Measurement Report : < 3G IVIeasurement Report struct > > } 
{ null I bit ** = < no string > -- Receiver compatible with earlier release 
I 1 -- Additions in Rel-5 : 

{ I 1 < G-RNTI extension : bit (4) > } 

< padding bits > } } ; 

< NC Measurement Report struct > ::= 

<NC_M0DE:bit(1)> 

< RXLEV_SERVING_CELL : bit (6) > 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

< NUMBER_OF_NC_MEASUREMENTS : bit (3) > 
{ < FREQUENCY_N : bit (6) > 

{ I 1 < BSIC_N : bit (6) > } 

< RXLEV_N : bit (6) > } * {val(NUMBER_OF_NC_MEASUREMENTS)) ; 

< 3G Measurement Report struct > ::= 

< N_3G: bit (3) > 

{ < 3G_CELL_LISTJNDEX : bit (7) > 

< REPORTING_QUANTITY : bit (6) > } * (val(N_3G + 1 )) ; 



Table 11.2.9.2: PACKET MEASUREMENT REPORT information element details 

TLLI / G-RNTI (32 bit field) 

This field contains the TLLI / G-RNTI of the mobile station. This field is encoded as defined in sub-clause 12.16. 

PSI5_CHANGE_MARK (2 bit field) 

This field shall contain the value of the PSI5_CHANGE_MARK in the PSI5 message containing the list of frequencies 
to measure. If the measurement order has been initiated by a PACKET MEASUREMENT ORDER message, the 
PSI5_CHANGE_MARK parameter shall be omitted from the message. 

BA_USED(1 bit field) 
3G_BA_USED (1 bit field) 
PSI3_CHANGE_MARK (2 bit field) 

In case of NC measurement report, these fields shall be included and contain the value of the B A_IND, 3G_B A_IND 
and PSI3_CHANGE_MARK respectively in the messages defining the used Neighbour Cell list. 

In case PBCCH exists, PSI3_CHANGE_MARK shall be used. 

In case PBCCH does not exist, BA_USED and 3G_BA_USED shall be used. 

PMO_USED(l bit field) 

This parameter shall contain the value of the PMO_IND in the PACKET CELL CHANGE ORDER or PACKET 
MEASUREMENT ORDER messages that has modified the used Neighbour Cell list. If no such message has been 
received, PMO_USED shall be set to zero. 

NC_MODE(l bit field) 

This field indicates if the mobile station was in mode NCI or NC2 when sending the measurement report. 

Mobile station in mode NCI 

1 Mobile station in mode NC2 
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RXLEV_SERVING_CELL (6 bit field) 

This field contains the value of the RXLEV parameter for the serving cell calculated by the mobile station (see 

3GPP TS 45.008). This field is encoded as the binary representation of the RXLEV parameter value defined in 

3GPP TS 45.008. 

Range to 63 

FREQUENCY_N (6 bit field) 

This field indicates the frequency/cell upon which the measurement was made. The field is an index into the resulting 

Frequency/Cell List for NCmeasurements. 

NC Measurements 

If PBCCH is allocated in the cell, the resulting frequency/cell list for NC Measurements is the GSM Neighbour Cell list 
defined in sub-clause 5.6.3.2. 

If PBCCH is not allocated in the cell, the resulting frequency/cell list for NC Measurements is 

- The BA(GPRS) (defined in sub-clause 5.6.3.2) before the MS has acquired the complete GSM Neighbour Cell 
list from the BCCH messages. In this case, the MS shall not include R99 extension ('Additions in release 99') in 
the PACKET MEASUREMENT REPORT message. 

The GSM Neighbour Cell list (defined in sub-clause 5.6.3.2) after the MS has acquired the complete GSM 
Neighbour Cell list from the BCCH messages. 

BSIC_N (6 bit field) 

This field indicates the BSIC of the frequency upon which the measurement was made. This field shall be included only 
for frequencies that refer to the BA(BCCH) Ust. The field is encoded as the BSIC value defined in 3GPP TS 44.018. 
Range to 63 

RXLEV_N (6 bit field) 

This field indicates the measured RXLEV of the frequency upon which the measurement was made (see 

3GPP TS 45.008). This field is encoded as the RXLEV value defined in 3GPP TS 44.018. 

Range to 63 

3G Measurements 

Measurement reporting for 3G Cells is defined in 3GPP TS 45.008. 

3G_CELL_LIST_INDEX (7 bit field) 

This is the index of the i'th reported 3G neighbour cell in the 3G Neighbour Cell List. See sub-clause 5.6.3.1. 

REPORTING_QUANTITY (6 bit field) 

This is the reporting quantity for the i'th reported 3G cell. The quantities are defined in 3GPP TS 45.008 for the 

respective Radio Access Technology. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier in lu mode. 



1 1 .2.9b Packet Measurement Order 

This message is sent on the PCCCH or PACCH by the network to a mobile station giving information for NC and EXT 
measurement reporting and network controlled cell reselection. If not all information fits into one message, the 
remaining information will be sent in other instances of the Packet Measurement Order message. 

Message type: PACKET MEASUREMENT ORDER 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.9b.1 : Packet Measurement Order information elements 

< Packet Measurement Order message content > ::= 

< PAGE_MODE : bit (2) > 

{ {0 <GlobalTFI :<GlobalTFI IE>> 
I 10 < TLLI / G-RNTI : bit (32) > } 
{ < PMOJNDEX : bit (3) > 

< PMO_COUNT : bit (3) > 

{ I 1 < NC Measurement Parameters : < NC Measurement Parameters struct > > } 
-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

{null I bit** = < no string > -- Receiver compatible with ealier release 

I 1 -- Additions in release 98 : 

{ I 1 < LSA Parameters : < LSA Parameters IE » } 
{ null I bit** = < no string > -- Receiver compatible with ealier release 

I 1 -- Additions in release 99 : 

{ I 1 < ENH Measurement Parameters : < ENH Measurement Parameters struct » } 
{ null I bit** = < no string > -- Receiver compatible with earlier release 

I 1 -- Additions in release R4 : 

< CCN_ACTIVE : bit > 

{ I 1 < CCN Support Description : < CCN Support Description struct » } 
{ null I bit ** = < no string > -- Receiver compatible with earlier release 
I 1 -- Additions in Rel-5 : 

{ I 1 < G-RNTI extension : bit (4) > } 
{ I 1 < lu Mode Neighbour Cell Parameters : 

{ 1 < lu Mode Neighbour Cell params struct > } ** > } 
-- Supplementary information for dual lu mode and A/Gb mode capable cells 
{ I 1 < NC lu MODE ONLY CAPABLE CELL LIST : NC lu Mode Only Cell List struct > } 
{ I 1 < GPRS 3G Additional Measurement Parameters Description 2 : 

< GPRS 3G Additional Measurement Parameters Description 2 struct » } 
{ null I bit** = < no string > -- Receiver compatible with earlier release 

I 1 -- Additions in release R6 : 

< 3G_CCN_ACTIVE : bit > 

< padding bits >}}}}} 

I < Non-distribution part error : bit (*) = < no string > > } 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

< NC Measurement Parameters struct > ::= 

< NETWORK_CONTROL_ORDER : bit (2) > 
{ I 1 < NC_ NON_DRX_PERIOD : bit (3) > 

< NC_REPORTING_PERIODJ : bit (3) > 

< NC_REPORTING_PERIOD_T : bit (3) > } 

{ I 1 < NC_FREQUENCY_LIST : < NC Frequency list struct > > } ; 

< NC Frequency list struct > ::= 

{ I 1 { < NR_OF_REMOVED_FREQ : bit (5) > 

{ < REMOVED_FREQJNDEX : bit (6) > } * (1 + val(NR_OF_REMOVED_FREQ)) } } 
{ 1 < List of added Frequency struct : < Add Frequency list struct > >} ** 0; 

< Add Frequency list struct > ::= 

< START_FREQUENCY : bit (10) > 

< BSIC : bit (6) > 

{ I 1 < Cell selection params : < Cell Selection struct > > } 

< NR_OF_FREQUENCIES : bit (5) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit (1 +val{FREQ_DIFF_LENGTH)) > 

< BSIC : bit (6) > 

{ I 1 < Cell selection params : < Cell Selection struct > > } } * {val(NR_OF_FREQUENCIES)); 
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< Cell Selection struct > ::= 

< CELL_BAR_ACCESS_2 : bit (1) > 

< EXC_ACC : bit > 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

{ I 1 < GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_IVIAX_CCH : bit (5) > } 

{ I 1 < GPRS_TEMPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TIME : bit (5) > } 

{ I 1 < GPRS_RESELECT_OFFSET : bit (5) > } 

{ I 1 < HCS params : < HCS struct > > } 

{ I 1 < SI13_PBCCH_L0CATI0N : < SI13_PBCCH_L0CATI0N struct > > } ; 

< SI13_PBCCH_L0CATI0N struct > ::= 

{ < SI13_L0CATI0N : bit (1) > 
I 1 < PBCCH_LOCATION : bit (2) > 

< PSI1_REPEAT_PERI0D : bit (4) > } ; 

< HCS struct > ::= 

< PRIORITY_CLASS : bit (3) > 

< HCS_THR : bit (5) > ; 

< ENH Measurement parameters struct > ::= 

{ < BAJND : bit >< 3G_BAJND : bit > | 1 < PSI3_CHANGE_MARK : bit{2) > } 

< PMOJND : bit > 

< REPORT_TYPE : bit > 

< REPORTING_RATE : bit > 

< INVALID_BSIC_REPORTING : bit > 

{ I 1 < 3G Neighbour Cell Description : < 3G Neighbour Cell Description struct » } 

{ I 1 < GPRS REP PRIORITY Description : <GPRS REP PRIORITY Description struct » } 

{ I 1 < GPRS MEASUREMENT Parameters Description : 

< GPRS IVIEASUREMENT PARAIVIETERS Description struct » } 
{ I 1 < GPRS 3G MEASUREMENT Parameters Description : 

< GPRS 3G MEASUREMENT PARAMETERS BIS Description struct » } ; 

< 3G Neighbour Cell Description struct> ::= 

{ I 1 < lndex_Start_3G : bit {7)> } 

{ I 1 < AbsoluteJndex_Start_EMR : bit (7)> } 

{ I 1 < UTRAN FDD Description : < UTRAN FDD Description struct > } 

{ I 1 < UTRAN TDD Description : < UTRAN TDD Description struct > } 

{ I 1 < CDMA2000 Description : < CDMA2000 Description struct > } 

{ I 1 < REMOVED_3GCELL_Description : < REMOVED_3GCELL_Description struct » } ; 

< REMOVED_3GCELL_Description struct > ::= 

< N1 : bit (2) > 

{ < N2 : bit (5) > 

{ < REM0VED_3GCELL_INDEX : bit (7) > 

< 3G_CELL_DIFF_LENGTH : bit (3) > 

< 3GCELL_DIFF : bit (val{3G_CELL_DIFF_LENGTH)) > 
}*{1+val{N2)) 

}*(1+val(N1)) ; 

< UTRAN FDD Description struct> ::= 

{ I 1 < Bandwidth_FDD : bit (3) > } 

{ 1 < Repeated UTRAN FDD Neighbour Cells : Repeated UTRAN FDD Neighbour Cells struct » } ** ; 

< Repeated UTRAN FDD Neighbour Cells struct > ::= 

< FDD-ARFCN : bit (14) > -- The value '1'was used in an earlier 

- version of the protocol and shall not be used. 

< FDDJndicO : bit > 

< NR_OF_FDD_CELLS : bit (5) > 

< FDD_CELLJNFORMATION Field : bit{p{NR_OF_FDD_CELLS)) > ; 

-- p(x) defined in table 1 1 .2.9b.2.a/3GPP TS 44.060 

< UTRAN TDD Description struct > ::= 

{ I 1 < Bandwidth_TDD : bit (3) > } 

{ 1 < Repeated UTRAN TDD Neighbour Cells : < Repeated UTRAN TDD Neighbour Cells struct » } ** ; 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 237 ETSI TS 144 060 V6.28.0 (2010-03) 

< Repeated UTRAN TDD Neighbour Cells struct > :;= 

< TDDJndicO : bit > 

< TDD-ARFCN : bit (1 4) > -- The value '1 ' was used in an earlier 

- version of the protocol and shall not be used. 

< NR_OF_TDD_CELLS : bit (5) > 

< TDD_CELLJNFORMATION Field : bit{q{NR_OF_TDD_CELLS)) > ; 

-- q(x) defined in table 1 1 .2.9b.2.b/3GPP TS 44.060. 

< CDMA 2000 Description struct> ::= 

< cdma2000 frequency band : bit (5) > 

< cdma2000 frequency : bit (1 1 ) > 

< number_cdma2000_cells : bit (5) > 

{ < Pilot PN offset : bit (9) > 

-- this information is enough for 1X Common Pilot 

{0 I 1{ 000 { <TD_MODE : bit (2) > <TD_POWER_LEVEL : bit (3) >} 
-- additional information for 1X Common Pilot with Transmit Diversity 

I 001 { < QOF : bit (2) > <WALSH_LEN_A : bit (3) > 

< AUX_PILOT_WALSH : bit(val(WALSH_LEN_A)+6)>} 
-- additional information for 1X Auxiliary Pilot 

I 010 { < QOF : bit (2) > <WALSH_LEN_B : bit (3) > 

< AUX_TD_WALSH : bit(val{WALSH_LEN_B)+8)> 

< AUX_TD_POWER_LEVEL : bit (2) > <TD_MODE : bit (2) >} 

-- additional information for IX Auxiliary Pilot with Transmit Diversity 

I 01 1 { < SR3_PRIM_PIL0T : bit (2) > <SR3_PIL0T_P0WER1 : bit (3) > 

< SR3_PILOT_POWER2 : bit (3) >} 

-- additional information for 3X Common Pilot 

I 1 10 { < SR3_PRIM_PIL0T : bit (2) > <SR3_PIL0T_P0WER1 : bit (3) > 

< SR3_PILOT_POWER2 : bit (3) > <QOF : bit (2) > 

< WALSH_LEN_C : bit (3) > 

< AUX_WALSH_LEN : bit{val(WALSH_LEN_C)+6)> 
{ I 1 < Q0F1 : bit (2) > < WALSH_LENGTH1 : bit (3) > 

< AUX_PIL0T_WALSH1 : bit{val(WALSH_LENGTH1)+6)>} 
{ I 1 < Q0F2 : bit (2) > <WALSH_LENGTH2 : bit (3) > 

<AUX_PIL0T_WALSH2 : bit(val{WALSH_LENGTH2)+6)>}} 
-- additional information for 3X Auxiliary Pilot 
} 
} 
} * val(number_cdma2000_cells) ; 

< GPRS REP PRIORITY Description struct> ::= 

< Number_Cells : bit{7) > 

{ < REP_PRIORITY : bit >} * (val(Number_Cells)) ; 
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< GPRS MEASUREMENT PARAMETERS Description struct > 
{ I 1 < MULTIBAND_REPORTING : bit (2) > } 
{ I 1 < SERVING_BAND_REPORTING : bit (2) > } 
< SCALE_ORD : bit(2) > 

{ I 1 < 900_REPORTING_OFFSET : bit (3) > 

< 900_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 1800_REPORTING_OFFSET : bit (3) > 

< 1800_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 400_REPORTING_OFFSET : bit (3) > 

< 400_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 1900_REPORTING_OFFSET : bit (3) > 

< 1900_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 850_REPORTING_OFFSET : bit (3) > 

< 850_REPORTING_THRESHOLD : bit (3) > } ; 



< GPRS 3G MEASUREMENT PARAMETERS BIS Description struct > 

< QsearchP : bit (4) > 

< 3G_SEARCH_PRI0 : bit > 

{ I 1 < FDD_REP_QUANT : bit > 

< FDD_MULTIRAT_REPORTING : bit (2) > } 



FDD Parameters 



{0 



{0 
{0 



1 < FDD_REPORTING_OFFSET : bit (3) > 

< FDD_REPORTING_THRESHOLD : bit (3) > } 

1 < TDD_MULTIRAT_REPORTING : bit (2) > } 
1 < TDD_REPORTING_OFFSET : bit (3) > 

< TDD_REPORTING_THRESHOLD : bit (3) > } 



TDD Parameters 



{ I 1 < CDMA2000_MULTIRAT_REPORTING : bit (2) > } 
{ I 1 < CDMA2000_REPORTING_OFFSET : bit (3) > 

< CDMA2000_REPORTING_THRESHOLD : bit (3) > } 



CDMA2000 Parameters 



< CCN Support Description struct > ::= 

< NumberCells : bit (7) > 

{ CCN_SUPPORTED : bit } * (val(Number_Cells)) ; 

< lu Mode Neighbour Cell Params struct > ::= 

{ I 1 < lu Mode Cell Selection Params : <lu Mode Cell Selection struct > > } 

< NR_OF_FREQUENCIES : bit (5) > 

{ I 1 < lu Mode Cell Selection Params : 

<lu Mode Cell Selection struct > > } * (val(NR_OF_FREQUENCIES)) ; 

< lu Mode Cell Selection struct > ::= 

< CELL BAR QUALIFY 3 : bit (2) > 

{ I 1 < SI13Alt PBCCH Location: < SI13 PBCCH Location struct > > } ; 

< NC lu Mode Only Cell List struct > ::= 

{ 1 < List of added cells : < Add lu Mode Only Cell List struct > >} ** 0; 

< Add lu Mode Only Cell List struct > ::= 

< START_FREQUENCY : bit (10) > 

< BSIC : bit (6) > 

{ I 1 < Cell selection params : < lu Mode Only Cell Selection struct > > } 

< NR_OF_FREQUENCIES : bit (5) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit {val(FREQ_DIFF_LENGTH)) > 

< BSIC : bit (6) > 

{ I 1 < Cell selection params : < lu Mode Only Cell Selection struct > > } } * (val{NR_OF_FREOUENCIES)) 
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< lu Mode Only Cell Selection struct > ::= 

< CELL BAR QUALIFY 3 : bit (2) > 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

{ I 1 < GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_MAX_CCH : bit (5) > } 
{ I 1 < GPRS_TEMPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TIME : bit (5) > } 

{ I 1 < GPRS_RESELECT_OFFSET : bit (5) > } 

{ I 1 < HCS params : < HCS struct > > } 

{ I 1 < SI13Alt_PBCCH_L0CATI0N : < SI13_PBCCH_L0CATI0N struct > > } ; 

< GPRS 3G Additional IVIeasurement Parameters Description 2 struct > ::= 

{ I 1 < FDD_REP0RTING_THRESH0LD_2 : bit (6) > } ; - FDD Parameters 



Table 11.2.9b.2 : Packet Measurement Order information element details 

The Packet Measurement Order message contains measurement parameters either for Network Control measurements If 
parameters for the NC measurements are not included, a previous Packet Measurement Order message belonging to the 
same set of messages shall still be valid.. 

The 'NC measurement parameters struct' contains the Network Control Order, the NC parameters and an NC Frequency 
List struct. If the value of the Network Control Order or any of the NC parameters differs between instances of the 
message, the value of the parameter in the instance with the highest PMO_INDEX shall be valid and all others shall be 
ignored. 

If included the NC Frequency List struct is a deviation list which contains removed or added frequencies to the 
BA(GPRS) hst (see 3GPP TS 45.008). The building of the resulting GSM Neighbour Cell hst is defined in sub- 
clause 5.6.3.2. 

The 'LS A parameters IE' contains a list of LSA_ID(s) corresponding to the entries in the 'Add Frequency list struct'. 
Some entries in 'LSA parameters IE' may be empty. The entries in the two structures are listed in the same order and the 
number of entries (nr_of_frequencies) should be the same. In case there are too few entries in the 'LSA parameters IE', 
empty entries shall be added at the end. In case there are too many entries in the 'LSA parameters IE', the last shall be 
discarded. The 'LSA parameters IE' is defined in sub-clause 12.28. 

The 'ENH Measurement parameters structure' contains information for performing enhanced measurements and 
reporting the measurement with the PACKET MEASUREMENT REPORT or 

PACKET ENHANCED MEASUREMENT REPORT message. For a 3G multi-RAT mobile station it may also include 
information for reporting on 3G Cells. 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PMOJNDEX (3 bit field) and PMO_COUNT (3 bit field) 

The purpose of the PMOJNDEX field and the PMO_COUNT field is to indicate the number of individual messages 
within the sequence of Packet Measurement Order messages and to assign an index to identify each one of them. The 
PMOJNDEX field is binary coded, range: to 7, and provides an index to identify the individual Packet Measurement 
Order message. The PMO_COUNT field is binary coded, range: to 7, and provides the PMOJNDEX value for the 
last (highest indexed) message in the sequence of Packet Measurement Order messages. A measurement order shall not 
be effected by the mobile station until all instances of a Packet Measurement Order message is received. 

Global TFI 

If present, this information element indicates the mobile station to which this message is addressed. This field is defined 
in sub-clause 12.10. 
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TLLI / G-RNTI (32 bit field) 

If present, this field indicates the mobile station to which this message is addressed. This field is defined in sub- 
clause 12.16. 

CCN_ACTIVE (1 bit field) 

This field indicates whether CCN is enabled in the serving cell for the mobile station when reselecting to a GSM cell. It 

is coded as follows: 

The broadcast CCN_ACTIVE parameter shall apply if available. Otherwise CCN is disabled in the cell for the 
mobile station when reselecting to a GSM cell. 

1 CCN is enabled in the cell for the mobile station when reselecting to a GSM cell. 

The NC Measurement Parameters gives the parameters for the serving cell and may contain frequency list deviations 
(add/delete) to the BA(GPRS) either on PBCCH or on BCCH. 

The NC_Measurement_Parameters struct contains the NETWORK_CONTROL_ORDER and the optional 
parameters NC_NON_DRX_PERIOD, NC_REPORTING_PERIOD_I, NC_REPORTING_PERIOD_T and the 
NC_FREQUENCY LIST. 

NETWORK_CONTROL_ORDER (2 bit field) 

The NETWORK_CONTROL_ORDER field is coded according to the following table (for definition of NCx see 

3GPP TS 45.008): 



Bit 




2 1 




00 


NCO 


01 


NCI 


1 


NC2 


1 1 


RESET 



NC_NON_DRX_PERIOD (3 bit field) 
NC_REPORTING_PERIOD_I (3 bit field) 
NC_REPORTING_PERIOD_T (3 bit field) 
For detailed element definitions, see the PSI5 message. 

NR_OF_REMOVED_FREQ (5 bit field) 

l+val(NR_OF_REMOVED_FREQ) indicates the number of frequencies in the B A-list which shall not be used for NC- 

measurements and gives the number of instances of the parameter REMOVED_FREQ_INDEX. 

Range of NR_OF_REMOVED_FREQ: to 31. 

REMOVED_FREQ_INDEX (6 bit field) 

This field indicates the index to the frequency to be removed in the BA(GPRS) sent on PBCCH or on BCCH, see sub- 
clause 5.6.3.2. 
Range: to 63. 

Add Frequency list struct contains the frequency list for NC measurements. 

START_FREQUENCY (10 bit field) 

FREQ_DIFF_LENGTH (3 bit field) 

FREQUENCY_DIFF (lH-val(FREQ_DIFF_LENGTH) bit field) 

For detailed element definition of these parameters, see the PSI5 message. 

BSIC (6 bit field) 

This field is encoded as the 'Base Station Identity Code' defined in 3GPP TS 23.003. 

Range to 63 
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The Cell selection params in the Add Frequency Hst struct shall be present for the first neighbour cell added by the 
message. For description of the cell selection parameters see Table: PSI3 information element details 

As an abnormal case, if the Cell selection params is missed for the first neighbour cell added by the message then the 
same parameters as the serving cell shall be applied as default value; 

If PCCCH is present in the serving cell then : 

CELL_BAR_ACCESS_2 : Serving cell CELL_BAR_ACCESS_2 

EXC_ACC : Serving cell EXC_ACC 

S AME_RA_AS_SERVING_CELL : The cell is in the same Routeing Area as the serving cell 

GPRS_RXLEV_ACCESS_MIN ; Serving cell GPRS_RXLEV_ACCESS_MIN 

GPRS_MS_TXPWR_MAX_CCH : Serving cell GPRS_MS_TXPWR_MAX_CCH 

GPRS_TEMPORARY_OFFSET : Serving cell GPRS_TEMPORARY_OFFSET 

GPRS_PENALTY_TIME : Serving cell GPRS_PENALTY_TIME 

GPRS_RESELECT_OFFSET : dB 

HCS_THR : Serving cell HCS_THR 

PRIORITY_CLASS : Serving cell PRIORITY_CLASS 

SI13_PBCCH_LOCATION : Undefined. 

If PCCCH is not present in the serving cell then : 

CELL_BAR_ACCESS_2 : Serving cell CELL_BAR_ACCESS 

EXC_ACC : Serving cell cell exclusive access support capability 

SAME_RA_AS_SERVING_CELL : The cell is in the same Routeing Area as the serving cell 

The other parameters default values take the same values as if the structure is present and optional fields are omitted 

(see below). 

In case the cell selection params is given, optional parameters which are not present shall be affected with the following 
default values : 

GPRS_RXLEV_ACCESS_MIN : Serving cell RXLEV_ACCESS_MIN 

GPRS_MS_TXPWR_MAX_CCH : Serving cell MS_TXPWR_MAX_CCH 

GPRS_TEMPORARY_OFFSET : Serving cell TEMPORARY_OFFSET 

GPRS_PENALTY_TIME : Serving cell PENALTY_TIME 

GPRS_RESELECT_OFFSET : dB 

HCS_THR : infinity 

PRIORITY_CLASS : undefined 

SI13_PBCCH_LOCATION : undefined 

The following neighbour cells defined in the message use the parameter values of the previous neighbour cell as their 
default values. 

ENH Measurement Parameters: 

BA_IND(1 bit field) 
3G_BA_IND(1 bit field) 
PSI3_CHANGE_MARK (2 bit field) 

These parameters are needed to allow the mobile station to associate the removed/added cells to the correct Neighbour 
Cell list. The values of this parameters are reflected in the PACKET ENHANCED MEASUREMENT REPORT 
message and in the PACKET MEASUREMENT REPORT message. 

In case PBCCH exists, PSI3_CHANGE_MARK shall be used. 

In case PBCCH does not exist, BA_IND and 3G_BA_IND shall be used. 

PMO_IND(l bit field) 

This parameter is needed to allow the network to discriminate measurements results related to Neighbour Cell list 
modified by different Packet Cell Change Order or Packet Measurement Order messages sent to the MS. The value of 
this parameter is reflected in the PACKET ENHANCED MEASUREMENT REPORT message and in the 
PACKET MEASUREMENT REPORT message. 
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REPORT_TYPE (1 bit) 

This parameter is used to indicate to the mobile station to use the PACKET MEASUREMENT REPORT or 

PACKET ENHANCED MEASUREMENT REPORT messages for (NC) reporting: 

If the cell has a PBCCH allocated: 
Bit 

The mobile station shall use the PACKET ENHANCED MEASUREMENT REPORT message for (NC) reporting 

1 The mobile station shall use the PACKET MEASUREMENT REPORT message for (NC) reporting 

If the cell has no PBCCH allocated: 
Bit 

The mobile station shall use the PACKET ENHANCED MEASUREMENT REPORT message for (NC) reporting 
if at least one BSIC is allocated to each BA(GPRS) frequency. Otherwise, the 

PACKET MEASUREMENT REPORT shall be used. 

1 The mobile station shall use the PACKET MEASUREMENT REPORT message for (NC) reporting 

REPORTING_RATE (1 bit) 

This parameter is used for measurements, see 3GPP TS 45.008. 

bit 

Normal rate reporting 

1 Reduced reporting rate allowed 

INVALID_BSIC_REPORTING (1 bit) 

This field specifies if cells with invalid BSIC and allowed NCC part of BSIC are allowed to be reported or not, see 

3GPPTS 45.008. 

bit 

Report on cells with invalid BSIC and allowed NCC part of BSIC is not allowed. 

1 Report on cells with invalid BSIC and allowed NCC part of BSIC is allowed. In this case NCC_PERMITTED is 
required in PSI5. 

3G Neighbour Cell Description: 

The building of the 3G Neighbour Cell list and the ordering of indices within each Radio Access Technology is 
described in sub-clause 5.6.3.1. 

Index_Start_3G (7 bit) 

This optional information element indicates the value of the first index to use to build this instance of the 3G Neighbour 

Cell list. When missing, the value is assumed. See sub-clause 5.6.3.1. 

Absolute_Index_Start_EMR (7 bit) 

This parameter indicates the value to be added to the indices of the 3G Neighbour Cell list for reporting 3G Cells with 
the PACKET ENHANCED MEASUREMENT REPORT message (see sub-clause 5.6.3.3). If present, it overrides the 
parameter value of the reference 3G Neighbour Cell list. If different values are received for this parameter in different 
instances of this message, the instance with the highest index shall be used. 

NOTE: This parameter is not used for reporting 3G Cells with the PACKET MEASUREMENT REPORT 

message, see sub-clause 11.2.9. 

UTRAN FDD Description: 

Bandwidth_FDD (3 bit field) 

This information element will be used for future releases of the protocol. When missing, this indicates the present FDD 
bandwidth. When present, this shall not be considered as an error; indices of the 3G Neighbour Cell list shall be 
incremented accordingly. 

FDD_ARFCN (14 bit field) 

This information element is defined as the UARFCN in 3GPP TS 25.101. Any non-supported frequency shall not be 

considered as an error; indices of the 3G Neighbour Cell list shall be incremented accordingly. 
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FDDjndicO, information indicator (1 bit): 

This field indicates if the ScrambHng Code/Diversity parameter value '0000000000' is a member of the set. 

Bit 

parameter value '0000000000' is not a member of the set 

1 parameter value '0000000000' is a member of the set 

NOTE: This bit FDDjndicO is equivalent to the bit FO bit in the frequency list information element (see 
3GPPTS 44.018). 

NR_OF_FDD_CELLS (5 bit field) 

This field defines the number of FDD_CELL_INFORMATION parameters. 

FDD_CELL_INFORMATION Field (p bit field) 

This field allows to compute a set of 10-bit-long FDD_CELL_INFORMATION parameters, re-using the Range 1024 
format compression algorithm, see 3GPP TS 44.018 Annex J: 'Algorithm to encode frequency list information'. The 
formulas for decoding are given in 3GPP TS 44.018: 'Range 1024 format'. The consecutive parameters of this field are 
concatenated, starting with wl, and then w2, w3... 

The total number of bits p of this field depends on the value of the parameter NR_OF_FDD_CELLS = n, as follows: 



n 


P 


n 


P 


n 


P 


n 


P 








5 


44 


10 


81 


15 


116 


1 


10 


6 


52 


11 


88 


16 


122 


2 


19 


7 


60 


12 


95 


17-31 





3 


28 


8 


67 


13 


102 






4 


36 


9 


74 


14 


109 







Table 11.2.9b.2.a 

If n=0 and FDDjndicO = 0, this indicates the 3G Neighbour Cell list index for report on RSSI, see 3GPP TS 45.008. 

If n is equal or greater than 17, this shall not be considered as an error; the corresponding index in the 3G Neighbour 
Cell list shall be incremented by one. 

For each (10-bit-long) decoded parameter, bits 1-9 are the Scrambling Code and bit 10 is the Diversity bit. 

Scrambling Code (9 bit field) 

This parameter indicates the Primary Scrambling Code as defined in 3GPP TS 25.213. 

Diversity (1 bit field) 

This parameter indicates if diversity is applied for the cell: 

Bit 

Diversity is not applied for this cell 

1 Diversity is applied for this cell. 

UTRAN TDD Description: 

Bandwidth_TDD (3bit field) 

This optional information element refers to 3GPP TS 25.331. 

Bit 

321 

000 3,84 Mcps 

001 1,28 Mcps 

All other values shall not be interpreted as an error; indices of the 3G Neighbour Cell list shall be incremented 
accordingly (but no reporting can be performed). When missing, this indicates 3,84 Mcps. 

TDD_ARFCN (14 bit field) 

This optional information element is defined as the UARFCN in 3GPP TS 25.102. Any non supported frequency shall 

not be considered as an error; indices of the 3G Neighbour Cell list shall be incremented accordingly. 
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TDDjndicO, information indicator (1 bit): 

This field indicates if the Cell_Parameter/Sync_Case/Diversity parameter value '0000000000' is a member of the set. 



Bit 



Bit 

parameter value '0000000000' is not a member of the set 

1 parameter value '0000000000' is a member of the set 

NR_OF_TDD_CELLS (5 bit field) 

This field defines the decimal value of the number of TDD_CELL_INFORMATION parameters. 

TDD_CELL_INFORMATION Field (q bit field) 

This field allows to compute a set of 9-bit-long TDD_CELL_INFORMATION aprameters, re -using the Range 512 
format compression algorithm, see 3GPP TS 44.018 Annex J: 'Algorithm to encode frequency list information'. The 
formulas for decoding are given in 3GPP TS 44.018 sub-clause 10.5.2.13.4: 'Range 512 format', with wO=0. The 
consecutive parameters of this field are concatenated, starting with wl, and then w2, w3... 

The total number of bits q of this field depends on the value of the parameter NR_OF_TDD_CELLS = m, as follows: 



m 


q 


m 


q 


m 


q 


m 


q 


m 


q 








5 


39 


10 


71 


15 


101 


20 


126 


1 


9 


6 


46 


11 


77 


16 


106 


21-31 





2 


17 


7 


53 


12 


83 


17 


111 






3 


25 


8 


59 


13 


89 


18 


116 






4 


32 


9 


65 


14 


95 


19 


121 







Table 11.2.9b.2.b. 

If m=0 and TDD_IndicO=0, or m is equal or greater than 21, this shall not be considered as an error; the corresponding 
index in the 3G Neighbour Cell list shall be incremented by one. 

For each (9-bit-long) decoded parameter, bits 1-7 are the Cell Parameter, bit 8 is the Sync Case TSTD and bit 9 is the 
Diversity TDD bit. 

Cell Parameter (7 bit field) 

This parameter is defined in 3GPP TS 25.223. 

Sync Case TSTD (1 bit field) 

For 3.84 Mcps TDD, this parameter is defined in 3GPP TS 25.223. 

Bit 

Sync Case 1 

1 Sync Case 2 

For 1.28 Mcps TDD, this parameter indicates if TSTD (see 3GPP TS 25.224) is applied for the cell: 
Bit 

TSTD is not applied for this cell 

1 TSTD is applied for this cell. 

Diversity TDD (1 bit field) 

This parameter indicates if SCTD (see 3GPP TS 25.224) is applied for the cell: 

Bit 

SCTD is not applied for this cell 

1 SCTD is applied for this cell. 

CDMA 2000 Description: 

cdma2000 frequency band (5 bit field) 

A binary representation of cdma2000 BAND_CLASS, as defined in TIA/EIA-IS -2000-5 -A. The mobile station shall 

ignore all the information relative to a cdma2000 frequency band that it can not support. 

cdma2000 frequency (1 1 bit field) 

A binary representation of cdma2000 CDMA_FREQ, as defined in TIA/EIA-IS -2000-5 -A. The mobile station shall 

ignore all the information relative to a cdma2000 frequency that it can not support. 
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number_cdma2000_cells (5 bit field) 

This field indicates the number of CDMA 2000 neighbour cells. 

Pilot PN offset (9 bit field) 

A binary representation of the PN offset of the Pilot PN sequence (in units of 64 cdma2000 Ix-chips), PILOT_PN, as 

defined in TIA/EIA-IS -2000-5 -A. 

TD_MODE (2 bit field) 

An indication of transmit diversity mode is specified in TIA/EIA-IS-2000-5-A. The mobile station shall ignore 

TD_MODE if it does not support IX Common Pilot with Transmit Diversity. 

TD_POWER_LEVEL (3 bit field) 

Power level of the Transmit Diversity Pilot relative to that of the Forward Pilot Channel as specified in TIA/EIA/IS- 

2000-5-A. The mobile station shall ignore TD_POWER_LEVEL if it does not support IX Common Pilot with Transmit 

Diversity. 

QOF (2 bit field) 

Quasi-orthogonal function index is defined in TIA/EIA/IS-2000-5-A. The mobile station shall ignore QOF if it does not 

support the quasi-orthogonal function. 

WALSH_LEN_A, WALSH_LEN_B and WALSH_LEN_C (3 bit field each) 

A three bit field to indicate the length of the Walsh code for the pilot that is used in as the Auxiliary Pilot, and specified 
as WALSH_LEN in TIA/EIA/IS -2000-5 -A. The mobile station shall ignore WALSH_LEN if it does not support IX 
Auxiliary Pilot. 

AUX_PILOT_WALSH (var.Length field) 

Indicates the walsh code corresponding to the Auxiliary Pilot, as specified in TIA/EIA/IS -2000-5 -A. The mobile station 

shall ignore AUX_PILOT_ WALSH if it does not support IX Auxiliary Pilot. 

AUX_TD_WALSH (var.Length field) 

Indicates the walsh code corresponding to the Auxiliary Transmit Diversity Pilot, as specified in TIA/EIA/IS -2000-5 -A. 

The mobile station shall ignore AUX_TD_WALSH if it does not support IX Auxiliary Pilot with Transmit Diversity. 

AUX_TD_POWER_LEVEL (2 bit field) 

Power level of the Auxiliary Transmit Diversity Pilot relative to that of the Forward Pilot Channel as specified in 
TIA/EIA/IS -2000-5 -A. The mobile station shall ignore AUX_TD_POWER_LEVEL if it does not support IX Auxiliry 
Pilot with Transmit Diversity. 

SR3_PRIM_PILOT (3 bit field) 

Position of the primary SR3 pilot as specified in TIA/EIA/IS-2000-5-A. The mobile station shall ignore 

SR3_PRIM_PILOT if it does not support 3X Common Pilot. 

SR3_PILOT_POWERl (3 bit field), relative power level between the primary SR3 pilot and the pilot on the lower 
frequency of the two remaining SR3 frequencies, as specified in TIA/EIA/IS -2000-5 -A. The mobile station shall ignore 
SR3_PILOT_POWERl if it does not support 3X Common Pilot. 

SR3_PILOT_POWER2 (3 bit field), relative power level between the primary SR3 pilot and the pilot on the higher 
frequency of the two remaining SR3 frequencies, as specified in TIA/EIA/IS-2000-5-A. The mobile station shall ignore 
SR3_PILOT_POWER2 if it does not support 3X Common Pilot. 

QOFl (2 bit field), WALSH_LEN1 (3 bit field) and AUX_PILOT_WALSHl (var. Length field) 
The corresponding quantities for pilot on the lower frequency of the two remaining SR3 frequencies, as specified in 
TIA/EIA/IS-2000-5-A. The mobile station shall ignore QOFl, WALSH_LEN1 and AUX_PILOT_WALSHl if it does 
not support 3X Auxiliary Pilot. 

QOF2 (2 bit field), WALSH_LENGTH2 (3 bit field) and AUX_PILOT_WALSH2 (var Length field) 
The corresponding quantities for pilot on the higher frequency of the two remaining SR3 frequencies, as specified in 
TIA/EIA/IS-2000-5-A. The mobile station shall ignore QOF2, WALSH_LEN2 and AUX_PILOT_WALSH2 if it does 
not support 3X Auxiliary Pilot. 
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REMOVED _3GCELL_Description 

This struct contains a list of cells to be removed from the 3G Neighbour Cell list for measurements (see sub-clause 
5.6.3.1). The cells are identified by their index. The struct consists of Nl sublists, each comprising the following three 
parameters: 

REMOVED_3GCELL_INDEX (7 bit field) 

This field indicates the index of the first cell in the sublist. 

3G_CELL_DIFF_LENGTH (3 bit field) 

This field indicates the number of bits used for the 3GCELL_DIFF field in the current sublist. 

3GCELL_DIFF (variable size) 

This field indicates the difference in index to the next cell in the sublist. 

GPRS REP PRIORITY Description 

REP_PRIORITY bit: 

Normal reporting priority 

1 High reporting priority 

The use of these bits is defined in sub-clause 5.6.3.5 and 3GPP TS 45.008. 

GPRS MEASUREMENT PARAMETERS Description 

The fields of this Description are used for measurements, as defined in 3GPP TS 45.008. 
Any parameter present overwrites any old data held by the mobile station for this parameter. 

GPRS 3G MEASUREMENT PARAMETERS Description 

The fields of this Description are used for measurements, as defined in 3GPP TS 45.008. 
Any parameter present overwrites any old data held by the mobile station for this parameter. 

GPRS 3G Additional Measurement Parameters Description 2 

The fields of this Description are used for measurements, as defined in 3GPP TS 45.008. 
Any parameter present overwrites any old data held by the mobile station for this parameter. 

CCN Support Description 

CCN_SUPPORTED (1 bit field) 

This parameter is used for determining whether the mobile station shall enter CCN mode when re-selecting a cell and 

CCN is enabled. The use of these bits is described in sub-clause°8.8.2a ("CCN support description"): 

Bit 

CCN is enabled towards the corresponding cell 

1 CCN is disabled towards the corresponding cell 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier in lu mode. 

lu Mode Neighbour Cell Parameters 

The lu mode Neighbour Cell Parameters shall only be included when the List of added Frequency struct is present. 
lu Mode Neighbour Cell Params Struct 

This struct presents supplementary information for lu mode capable cells. The struct assigns lu mode parameter values 
to the neighbouring cells defined by the message. The lu mode Neighbour Cell params struct values are assigned to the 
neighbouring cells in the same order they appear in the List of added Frequency struct. 

NC lu Mode Only Capable Cell List Parameters 

These parameters are used to add lu mode only capable cells to BA(GPRS) list. 
CELL BAR QUALIFY 3 (2 bit field) 

This information element is defined in 3GPP TS 44.018. 
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3G_CCN_ACTIVE (1 bit field) 

This field indicates whether CCN is enabled towards 3G i 


leighbouring cells. 


It is coded 


as follows: 





The broadcast 3G_CCN_ACTIVE parameter shall 
disabled in the cell. 


apply if available. 


Otherwise, 


CCN towards 3G cells is 


1 


CCN towards 3G cells is enabled in the cell. 









1 1 .2.9b.1 GPRS REP PRIORITY description 

A GPRS REP PRIORITY description construction shall be included in one and only one instance of the PACKET 
MEASUREMENT ORDER message within the consistent set of PACKET MEASUREMENT ORDER messages. 

1 1 .2.9c Packet Mobile TBF Status 

This message is sent from the mobile station to the network on the uplink PACCH to indicate erroneous messages have 
been received relating to either a downlink or an uplink TBF. 

Message type: PACKET MOBILE TBF STATUS 

Direction: mobile station to network 

Table 11.2.9c.1 : Packet MOBILE TBF STATUS information elements 



< Packet Mobile TBF Status message content > ;:= 

< GLOBAL TFI : < Global TFI IE > > 

< TBF_CAUSE : bit (3) > 

{ I 1 < STATUS_MESSAGE_TYPE : bit (6) > } 

< padding bits > ; 



Table 11.2.9c.2: Packet MOBILE TBF STATUS information element details 



Global TFI IE 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

TBF_CAUSE (3 bit field) 

The TBF_CAUSE field indicates the error cause value of the current TBF. This field is encoded according to the 

following table: 

Bit 

321 

Normal event; 

1 Status, unspecified; 

10 Syntactically incorrect message, non-distribution part error; 

Oil Syntactically incorrect message, message escape; 

10 Message not compatible with current protocol state. 

All other values are reserved and may be interpreted "Status, unspecified". 

STATUS_MESSAGE_TYPE (6 bit field) 

The STATUS_MESSAGE_TYPE field, if present, is the binary representation of the message type of the downlink 

RLC/MAC control message that caused the status condition. Message type values are defined in sub-clause 11.2.0.1. 



1 1 .2.9d Packet Enhanced Measurement Report 

This message is sent either on the PACCH if in packet transfer mode or on an assigned block on a PDTCH, from the 
mobile station to the network to report enhanced measurement results. The message contains measurement results from 
the Network Control measurements. 

Message type: PACKET ENHANCED MEASUREMENT REPORT 
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Direction: mobile station to network 

Table 11. 2.9d.1: PACKET ENHANCED MEASUREMENT REPORT message content 

< PACKET ENHANCED MEASUREMENT REPORT message content > ::= 

< TLLI / G-RNTI : bit (32) > 

{ < NC Measurement Report : < NC Measurement Report struct > > } 
{ null I bit ** = < no string > -- Receiver compatible with earlier release 
I 1 -- Additions in Rel-5 : 

{ I 1 < G-RNTI extension : bit (4) > } 

< padding bits > } ; 

< NC Measurement Report struct > ::= 
<NC_M0DE:bit(1)> 

{ < BA_USED : bit >< 3G_BA_USED : bit > | 1 < PSI3_CHANGE_MARK : bit{2) > } 

< PMO_USED : bit > 

< BSIC_Seen : bit > 

< SCALE : bit > 

{ I 1 < Serving cell data : < Serving cell data struct » } 

{ 1 < Repeated lnvalid_BSIC_lnformation : < Repeated lnvalid_BSIC_lnformation struct » } ** 

{ I 1 {0 I 1 < REPORTING_QUANTITY : bit (6) > } ** } ; - bitmap type reporting 

< Serving cell data struct > ::= 

< RXLEV_SERVING_CELL : bit (6) > 

; -- The value '1' was allocated in an earlier version of the protocol and shall not be used. 

< Repeated lnvalid_BSIC_lnformation struct > ::= 

< BCCH-FREQ-NCELL : bit (5) > 

< BSIC : bit (6) > 

< RXLEV-NCELL : bit (6) > ; 



Table 11.2.9d.1: PACKET ENHANCED MEASUREMENT REPORT information element details 

TLLI / G-RNTI (32 bit field) 

This field contains the TLLI / G-RNTI of the mobile station. This field is encoded as defined in sub-clause 12.16. 

NC_MODE(l bit field) 

This field indicates if the mobile station was in mode NCI or NC2 when sending the measurement report. 

Mobile station in mode NCI 

1 Mobile station in mode NC2 

BA_USED(1 bit field), 
3G_BA_USED (1 bit field) 
PSI3_CHANGE_MARK (2 bit field) 

These fields shall contain the value of the BAJND, 3G_BA_IND and PSI3_CHANGE_MARK respectively in the 
messages defining the used Neighbour Cell list. 

In case PBCCH exists, PSI3_CHANGE_MARK shall be used. 

In case PBCCH does not exist, BA_USED and 3G_BA_USED shall be used. 

PMO_USED(l bit field) 

This parameter shall contain the value of the PMO_IND in the PACKET CELL CHANGE ORDER or PACKET 
MEASUREMENT ORDER messages that has modified the used Neighbour Cell list. If no such message has been 
received, PMO USED shall be set to zero. 
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BSIC_Seen(l bit field) 

This parameters indicates if a GSM cell with invalid BSIC and allowed NCC part BSIC is one of the six strongest, see 

3GPPTS 45.008. 

Bit 

No cell with invalid BSIC and allowed NCC part of BSIC is seen 

1 One cell or more with invalid BSIC and allowed NCC part of BSIC is seen 

SCALE (1 bit field) 

The value of this field is defined in 3GPP TS 45.008. 

Serving cell reporting 

If the structure "serving cell data" is missing, this indicates that no valid measurement exist for the serving cell. 

RXLEV_SERVING_CELL (6 bit field) 

This field contains the value of the RXLEV parameter for the serving cell calculated by the mobile station (see 

3GPP TS 45.008). This field is encoded as the binary representation of the RXLEV parameter value defined in 

3GPPTS 45.008. 

Range to 63 

Neighbour cell reporting 

Repeated Invalid BSIC 

This structure contains the report of cells with invalid BSIC. 

BCCH-FREQ-NCELL (5 bits). This field represents the index of the BA(GPRS), see 3GPP TS 44.018. 

BSIC (6 bits). Base station identity code of the corresponding index in the BA(GPRS). 

RXLEV (6 bits). GSM reporting quantity, see 3GPP TS 45.008. 

Bitmap type reporting: 

This structure contains the report of cells with valid BSIC. 

Each bit of the bitmap points to the corresponding index of the Neighbour Cell list defined in sub-clause 5.6.3.3 

("Deriving the Neighbour Cell hst from the GSM Neighbour Cell list and the 3G Neighbour Cell Ust"). 

If this structure is present and more bits than needed are available at the end of the message, the MS shall set the value 
of the redundant bitmap positions to '0'. 

At least 96 neighour cell entries shall be encoded in the bitmap. 

If this structure is present, some remaining bits indicating no report at the end of the message may be omitted if these 
bits do not fit into the message. This shall not lead to an error in the receiver of that message. 

REPORTING_QUANTITY (6 bits): 

Measurement quantities are defined in 3GPP TS 45.008. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier in lu mode. 



1 1 .2.9e Packet Neighbour Cell Data 

This optional message is sent by the network on the PACCH to provide system information required for initial access in 
a neighbouring cell. This message shall not be segmented across more than one RLC/MAC control block. If not all 
information fits into one instance of the PACKET NEIGHBOUR CELL DATA message, the message can be repeated. 

Message type: PACKET NEIGHBOUR CELL DATA 

Direction: network to mobile station 

Classification: non distribution message 
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Table 1 1 .2.9e.1 : Packet Neighbour Cell Data information elements 



< Packet Neighbour Cell Data message content > ::= 


< PAGE MODE : bit (2) > 


{ < Global TFI : < Global TFI IE > > 


{ < CONTAINERJD : bit (2) > 


< spare : bit (1) 


< CONTAINERJNDEX : bit (5) > 


{0| 1 <ARFCN:bit{10)> 


< BSIC : bit (6) > } 


< CONTAINER : < Container repetition struct > > 


< padding bits > 


I < Non-distribution part error : bit (*) = < no string > > } 


! < Address information part error : bit (*) = < no string > > } 


! < Distribution part error : bit (*) = < no string > > ; 


< Container repetition struct > ::= 
1 


{ < PD : bit (3) > 


< CD_LENGTH : { bit (5) exclude 00000 exclude 1 1 1 1 1 } > 


< CONTAINER_DATA : octet (val(CD_LENGTH)) > - Final container segment. Next container follows. 


1 < PD : bit (3) > 


< CD_LENGTH : { bit (5) := 1 1 1 1 1 } > 


< CONTAINER_DATA : octet **>}** - Container continued in next message. 


{ < spare bit (3) > -- Repetition of tfie container repetition struct continues until: 


< CD_LENGTH : { bit (5) := 00000 } > } -A) val(CD_LENGTH) = or 


} // ; -- B) end of PNCD message. 



Table 11.2.9e.2: Packet Neighbour Cell Data information element details 



The Packet Neighbour Cell Data message consists of up to 32 instances and contains neighbour cell system information 
messages from either the BCCH or from the PBCCH or from both. Each container repetition struct contains information 
from one or more SI/PSI message. One SI/PSI message can be distributed over more than one instance. 

A container may have the cell identity represented by the ARFCN and BSIC included. 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20 and gives the PAGE_MODE parameter valid in the serving cell. 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

CONTAINERJD (2 bit field) 

This field contains the Container identity and shall have the same value in all instances to form a complete set of 

neighbour cell system information for a certain cell. 

Value range: 0-3. 

Spare (1 bitfield) 

This bit is reserved for future use. 

CONTAINERJNDEX (5 bit field) 

This field contains the message index within a complete set of neighbour cell system information for a certain cell 

Value range: 0-31. 
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ARFCN and BSIC 

ARFCN and BSIC is optional, but if included their value shall be same in all instances forming a complete set. If not 
the same, the mobile station shall act as described in sub-clause 8.8.1. 

ARFCN (10 bit field) 

This field indicates the ARFCN of the BCCH of the neighbour cell for which the information contained in this message 

is valid for. This field is encoded as the ARFCN defined in 3GPP TS 44.018. 

Range to 1023 

BSIC (6 bit field) 

This field indicates the BSIC of the neighbour cell for which the information contained in this message is valid. 

This field is encoded as the BSIC value defined in 3GPP TS 44.018. 
Range to 63 

PD (3 bit field) 

This field contains a protocol discriminator and indicates the origin of the contained message. 

bit 

2 1 

BCCH (LAPDm); 

1 PBCCH (RLC/MAC); 

10 Reserved; If received the contents of the container shall be discarded. 



Ill Reserved;. If received the contents of the container shall be discarded. 

CD_LENGTH (5 bit field) 

This field indicates the number of CONTAINER DATA octets that forms a specific SI/PSI message and is coded as 

shown below. 

bit 

5432 1 

No CONTAINER DATA follows; Spare padding is used to fill the rest of the message; 

1 CONTAINER DATA length = 1 octet; 

10 10 CONTAINER DATA length = 18 octets; 

11111 The remaining portion of the Packet Neighbour Cell Data message is used by the associated 

CONTAINER DATA. The message continues in a subsequent instance of the Packet Neighbour Cell 
Data message, in the next CONTAINER DATA with the same Protocol Discriminator value as the 
current one. 

All other values reserved. If a reserved value is received the contents of the container shall be discarded. 

CONTAINER_DATA(n*8 bits) 

The concatenation of one or several CONTAJNER_DATA octets forms the actual contents, specific to the SI/PSI 

messages. 

If the contained system information messages are copied from the BCCH the information contained in the Packet 
Neighbour Cell Data message shall exclude the following information elements from the beginning of the messages: L2 
Pseudo Length; RR management Protocol Discriminator and Skip Indicator. 

If the contained system information messages are copied from the PBCCH the information contained in the Packet 
Neighbour Cell Data message shall include the complete PSI message. 

Extra octets of padding bits at the end of the SI/PSI messages may be excluded. 



11 .2.1 Packet Paging Request 

This message is sent on the PCCCH by the network to trigger channel access by up to four mobile stations, for either 
TBF or RR connection establishment. It may also be sent on PACCH to a mobile station in packet transfer mode to 
indicate page request for RR connection establishment. The mobile stations are identified by either IMSI, TMSI, P- 
TMSI or G-RNTI. Depending on the method used to identify the mobile station, 1-4 mobile stations can be addressed 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 252 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

in the message. The PACKET PAGING REQUEST message may also be used to send MBMS (PRE-)notifications. 
Special requirements for the transmission of this message on PACCH applies, see 3GPP TS 45.002. 

Message type: PACKET PAGING REQUEST MESSAGE 

Direction: network to mobile station 

Classification: distribution message 

Table 11.2.10.1: PACKET PAGING REQUEST message content 

< Packet Paging Request message content > ::= 

< PAGE_MODE : bit (2) > 

{ I 1 < PERSISTENCE_LEVEL : bit (4) >* 4} 

{0| 1 <NLN(PPCH) :bit(2)>} 

{ { 1 < Repeated Page info : < Repeated Page info struct > > } ** 

{null |0 bit** = < no string > - Receiver compatible with earlier release 

I 1 -- REL-5 additions: 

{ 1 < Repeated lu Page info : < Repeated lu Page info struct > > } ** 
{ null I bit** = < no string > - Receiver compatible with earlier release 

I 1 -- REL-6 additions: 

{ I 1 < IVIBMS Information > } 
{ I 1 < NLN status(PPCH) : bit (1 ) > } 

< padding bits >}}}// -- truncation at end of message allowed, bits '0' assumed 
! < Distribution part error : bit (*) = < no string > > ; 

< Repeated Page info struct > ::= 

{ -- Page request for TBF establishment 

{ < PTMSI : bit (32) > 
I 1 < Length of IVIobile Identity contents : bit (4) > 

< Mobile Identity : octet (val (Length of Mobile Identity contents)) > } 

I 1 -- Page request for RR conn, establishment 

{ < TMSI : bit (32) > 
I 1 < Length of Mobile Identity contents : bit (4) > 

< Mobile Identity : octet (val (Length of Mobile Identity contents)) > } 

< CHANNEL_NEEDED : bit (2) > 

{ I 1 < eMLPP_PRIORITY : bit (3) > } } 
! < Ignore : bit (*) = <no string> > ; 

< Repeated lu Page info struct > ::= 

{ 

{ < G-RNTI: bit(32) > -- used for a CN page to an t\AS in RRC connected mode, era GERAN initiated page 

{ I 1 < Page Info struct : < Page info struct > > } -- only included for a CN page 

|1 

{ 00 < TMSI : bit (32) > 

I 01 < PTMSI : bit (32) > 

I 1 1 { < Length of Mobile Identity contents : bit (4) > 

< Mobile Identity : octet (val (Length of Mobile Identity contents)) > } 

< Page info struct : < Page info struct > > } 
{ I 1 < eMLPP_PRIORITY : bit (3) > } } 

I < Ignore : bit (*) = <no string> > ; 

< MBMS Information > ::= 

{ 

-- Pre-notifications 

< MBMS Sessions List : < MBMS Sessions List IE > > 

-- Notifications: listed per MBMS Channel Parameters 

{ 1 < MBMS Channel Parameters : < MBMS Channel Parameters IE > > 

< MBMS Sessions List : < MBMS Sessions List IE > > } ** } } 
I < Ignore : bit (*) = <no string> > ; 

< Page info struct > :: = 

< PAGING CAUSE : bit (3) > 

< CN DOMAIN IDENTITY : bit (2) > 

{ I 1 < Paging Record Type Identifier : bit (2) > }; -- This field Is only included if the MS is paged using a G-RNTI 
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Table 11.2.10.2: PACKET PAGING REQUEST information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PERSISTENCE_LEVEL (4 bit field for each Radio Priority 1...4) 
This field is defined in sub-clause 12.14, PRACH Control Parameters. 

NLN(PPCH) (2 bit field) 

Notification List Number - This field may only be present if the message contains at least one page request for an RR 
connection establishment. The presence of the NLN(PPCH) field indicates that if an NCH is present, reduced NCH 
monitoring can be used, and gives the NLN(PPCH) value, to be used as specified in 3GPP TS 44.018.The field is coded 
as defined in the PI Rest Octets information element in 3GPP TS 44.018. 

NLN status(PPCH) (1 bit field) 

Notification List Number status - This field may only be present if the message contains at least one page request for an 
RR connection establishment.The NLN status indicates the status of the content of the NOTIFICATION/NCH 
messages for a particular NLN value. A change of the NLN status field indicates a change of information on the NCH 
which is not related to new calls, as specified in 3GPP TS 44.018. The field is coded as defined in the PI Rest Octets 
information element in 3GPP TS 44.018. 

Repeated Page info struct 

The Repeated Page info struct is repeated as many times as required to fulfil the number of wanted paged mobiles. If 
the Paging Request Message is used with only P-TMSIs or TMSIs, the field can be repeated up to four times within one 
message. If the Paging Request Message is used with only IMSIs, the field can be repeated up to two times within one 
message. 

The first bit in the Repeated Page info field indicates if this is a page request for TBF connection establishment or for 
RR connection establishment. 

A page request for TBF connection establishment can either be addressed with P-TMSI or IMSI. 

A page request for RR connection establishment contains a Channel Needed and optionally a Priority parameter and can 
either be addressed with TMSI or IMSI. 

PTMSI (32 bit field) 

The Packet Temporary Mobile Station Identity (PTMSI) is defined in 3GPP TS 23.003. This field is encoded as a 

binary number. 

Range to 4294967295 

Mobile Identity (variable length octet string) 

This octet string is the representation of the Mobile Identity. It shall provide the international mobile subscriber identity, 
IMSI. The encoding of this octet string is the value part (starting with octet 3) of the type 4 information element Mobile 
Identity defined in 3GPP TS 44.018. 

Any value other than IMSI for the type of identity in this octet string is spare. Such mobile identity shall be disregarded 
by the receiver but any further occurrence of the Repeated Page Info struct in the message shall be analysed. 

TMSI (32 bit field) 

TMSI is a unique Temporary Mobile Subscriber Identity. TMSI is associated with the mobile subscriber and defined in 

3GPP TS 23.003. This field is coded as a binary number. 

Range to 4294967295 

CHANNEL_NEEDED (2 bit field) 

The channel needed field indicates which type of channel is needed for the mobile station for the transaction linked to 

the paging procedure. The field is coded according to following table; 

bit 
2 1 

Any channel 

1 SDCCH 

1 TCH/F (Full rate) 

1 1 TCH/H or TCH/F (Dual rate) 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 254 ETSI TS 144 060 V6.28.0 (2010-03) 

eMLPP_PRIORITY (3 bit field) 

The optional eMLPP_PRIORITY field relates to Mobile Station Identity i(i = 1,2,3,4) and may only be present when 
the page relates to a paging request to trigger RR/RRC connection establishment. The eMLPP_PRIORITY field is 
coded as the Priority field defined in the PI Rest Octets information element in 3GPP TS 44.018. 

Repeated MBMS Notification info struct 

The Repeated MBMS Notification info struct is repeated as many times as required to fulfil the number of wanted 
paged Temporary Mobile Groups. 



The MBMS session identity is optional and shall be included whenever being made available in the MBMS Session 
Start Request Message received from the SGSN. 

If no counting should take place then a MBMS p-t-m channel description may be included. 

If counting is requested then a MPRACH description may be included. 

MBMS Sessions List 

This information element contains a list of MBMS sessions identified by their TMGI and if available MBMS Session 
Identity. This information element is defined in sub-clause 12.39. 

MBMS Channel Parameters 

This information element contains the MBMS channel parameters of one or more MBMS sessions. This information 
element is defined in sub-clause 12.36. 

Page info struct 

This struct contains all information to be passed between RLC/MAC and RRC in the MS. 

Repeated Iu_Page info struct 

The Repeated Iu_Page info struct is repeated as many times as required to fulfil the number of wanted paged mobiles. If 
the PACKET PAGING REQUEST message is used with only P-TMSIs, TMSIs or G-RNTIs, the field can be repeated 
up to four times within one message. If the Paging Request Message is used with only IMSIs, the field can be repeated 
up to two times within one message. 

G-RNTI (32 bits) 

The G-RNTI field identifies the MS within GERAN when an RRC connection exists between this MS and GERAN. G- 

RNTI is defined in 3GPP TS 44.118. 

PAGING RECORD TYPE IDENTIFIER (2 bits field) 

The Paging Record Type Identifier field indicates the type of identity used in the core network page, as it is defined in 

3GPP TS 44.1 18. This field shall be included in the message if the MS is identified in the page with a G-RNTI 

bit 
2 1 

IMSI (GSM-MAP) 

1 TMSI (GSM-MAP) / P-TMSI 

1 IMSI (DS-41) 
1 1 TMSI (DS-41) 

CN DOMAIN IDENTITY (2 bit field) 

The CN Domain Identity field indicates the domain of the core network from which the MS is paged, as defined in 

3GPPTS44.118. 



Bit 




21 




00 


CS domain 


01 


PS domain 


1 


Either 


1 1 


Reserved 
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PAGING CAUSE (3 bits field) 

The Paging Cause field indicates the cause for paging, as defined in 3GPP TS 44. 118. 

bit 

321 

Terminating Conversational Call 

1 Terminating Streaming Call 

10 Terminating Interactive Call 

Oil Terminating Background Call 

10 Terminating High Priority Signalling 

10 1 Terminating Low Priority Signalling 

110 Terminating - cause unknown 

111 Reserved 



11.2.11 Packet PDCH Release 

This message is sent on PACCH by the network to notify all mobile stations listening to that PDCH that one or more 
PDCHs will be immediately released and become unavailable for packet data traffic. 

Message type: PACKET PDCH RELEASE 

Direction: network to mobile station 

Classification: distribution message 

Table 11.2.11.1: PACKET PDCH RELEASE information elements 

< Packet PDCH Release message content > ::= 

< PAGE_MODE : bit (2) > 

{ 1 < TIMESLOTS_AVAILABLE : bit (8) > } 

< padding bits > 

! < Distribution part error : bit (*) = < no string > > ; 

Table 11.2.11.2: PACKET PDCH RELEASE information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

TIMESLOTS_AVAILABLE (8 bit field) 

This information field indicates the timeslots assigned for GPRS use on the current MAIO or ARFCN. Bit 8 indicates 

the status of timeslot 0, bit 7 indicates the status of timeslot 1, etc. 

Timeslot is not assigned 

1 Timeslot is assigned 



NOTE: If the bit preceding the parameter TIMESLOTS_AVAILABLE is received = a distribution part error 
should be generated by the mobile station. To allow compatibility with early GPRS mobile stations in 
Release 97 such mobile stations may interpret this message, if received with the bit preceding the 
parameter TIMESLOTS_AVAJLABLE equal to 0, as a command to release the timeslot on which the 
message was received. 

1 1 .2.1 2 Packet Polling Request 

This message is sent on the PCCCH or PACCH by the network to the mobile station to solicit a PACKET CONTROL 
ACKNOWLEDGEMENT message from the mobile station. 

Message type: PACKET POLLING REQUEST 

Direction: network to mobile station 
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Classification: non-distribution message 

Table 11.2.12.1: PACKET POLLING REQUEST information elements 

< Packet Polling Request message content > ::= 
< PAGE_MODE : bit (2) > 
{ {0 <GlobalTFI :<GlobalTFI IE>> 
I 10 < TLLI / G-RNTI : bit (32) > 
I 110 <TQI :bit(16)>} 
{ < TYPE_OF_ACK : bit (1) > 

{ null I bit ** = < no string > -- Receiver compatible with earlier release 
I 1 -- Additions in Rel-5 : 
{ I 1 < G-RNTI extension : bit (4) > } 
< padding bits > } 
I < Non-distribution part error : bit (*) = < no string > > } 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

Table 11.2.12.2: PACKET POLLING REQUEST information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

TQI (16 bit field) 

This field is defined in sub-clause 12.17. 

TLLI / G-RNTI (32 bit field) 

This field is defined in sub-clause 12.16. 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

TYPE_OF_ACK 

This field indicates the format of the PACKET CONTROL ACKNOWLEDGEMENT message requested from the 
mobile station by the PACKET POLLING REQUEST message. 

PACKET CONTROL ACKNOWLEDGEMENT message format shall be sent as four access bursts 

1 PACKET CONTROL ACKNOWLEDGEMENT message format shall be an RLC/MAC control block 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier in lu mode. 



11 .2.1 3 Packet Power Control/Timing Advance 

This message is sent on PACCH by the network to the mobile station in order to update the mobile station timing 
advance or power control parameters. 

Message type: PACKET POWER CONTROL/TIMING ADVANCE 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.13.1: PACKET POWER CONTROL/TIMING ADVANCE information elements 

< Packet Power Control/Timing Advance message content > ::= 

< PAGE_MODE : bit (2) > 

{ < Global TFI :< Global TFI IE >> 
{ -- Message escape 

{ { I 1 < Global Power Control Parameters : < Global Power Control Parameters IE » } 
{ < Global Packet Timing Advance : < Global Packet Timing Advance IE > > 

< Power Control Parameters : < Power Control Parameters IE > > 
I 1 { < Global Packet Timing Advance : < Global Packet Timing Advance IE > > 
I 1 < Power Control Parameters : < Power Control parameters IE > > } } 
{ null I bit** = < no string > - Receiver backward compatible witli earlier version 
I 1 -- Additions for R99 

{ I 1 <Packet Extended Timing Advance : bit {2)> } 

< padding bits > } 

! < Non-distribution part error : bit (*) = < no string > > } 
! < Message escape : 1 bit (*) = <no string> > } 
I < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

Table 11.2.13.2: PACKET POWER CONTROL/TIMING ADVANCE information element details 

Global Power Control Parameters IE 

This information field is defined in sub-clause 12.9. 

Global_Packet Timing Advance IE 

This information field is defined in sub-clause 12.12a. 

Power Control Parameters IE 

This information field is defined in sub-clause 12.13. 

Global TFI IE 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 



11 .2.1 4 Packet PRACH Parameters 

This message is sent on the PCCCH by the network to all mobile stations within the cell to update the PRACH 
parameters in between Packet System Information messages containing PRACH parameters. 

Message type: PACKET PRACH PARAMETERS 

Direction: network to mobile station 

Classification: distribution message 

Table 11.2.14.1: PACKET PRACH PARAMETERS information elements 

< Packet PRACH Parameters message content > ::= 

< PAGE_MODE : bit (2) > 

< PRACH Control Parameters : < PRACH Control Parameters IE > > 

< padding bits > 

! < Distribution part error : bit (*) = < no string > > ; 

Table 11.2.14.2: PACKET PRACH PARAMETERS information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 
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PRACH Control Parameters 

This information element is defined in sub-clause 12.14. 



11.2.15 Packet Queueing Notification 

This message is sent on the PCCCH by the network to the mobile station to notify the mobile station that it is being 
placed in queue. The message allocates a Temporary Queueing Identity to the mobile station. 

Message type: PACKET QUEUEING NOTIFICATION 

Direction: network to mobile station 

Classification: non-distribution message 

Table 11.2.15.1: PACKET QUEUEING NOTIFICATION information elements 

< Packet Queueing Notification message content > ::= 
< PAGE_MODE : bit (2) > 

{ 111 < Packet Request Reference : < Packet Request Reference IE > > 
{ <TQI :bit(16)> 
< padding bits > 

! < Non-distribution part error : bit (*) = < no string > > } 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

Table 11.2.15.2: PACKET QUEUEING NOTIFICATION information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Packet Request Reference 

This information element is defined in sub-clause 12.1 1. 

TQI (16 bit field) 

This information field is defined in sub-clause 12.17. 



1 1 .2.1 6 Packet Resource Request 

This message is sent on the PACCH by the mobile station to the network to request a change in the uplink resources 
assigned. 

Message type: PACKET RESOURCE REQUEST 

Direction: mobile station to network 
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Table 11.2.16.1: PACKET RESOURCE REQUEST information elements 

< Packet Resource Request message content > ::= 
{ I 1 < ACCESS_TYPE : bit (2) > } 
{ < Global TFI : < Global TFI IE > > 
I 1 < TLLI / G-RNTI : < TLLI / G-RNTI IE > > } 
{ I 1 < MS Radio Access Capability 2 : < MS Radio Access Capability 2 IE > > } 

< Channel Request Description : < Channel Request Description IE > > 
{ I 1 < CHANGE_MARK : bit (2) > } 

< C_VALUE : bit (6) > 

{ I 1 < SIGN_VAR : bit (6) >} 

{ I 1 < l_LEVEL_TNO : bit (4) > } 

{ I 1 < l_LEVEL_TN1 : bit (4) > } 

{ I 1 < l_LEVEL_TN2 : bit (4) > } 

{ I 1 < l_LEVEL_TN3 : bit (4) > } 

{ I 1 < l_LEVEL_TN4 : bit (4) > } 

{ I 1 < l_LEVEL_TN5 : bit (4) > } 

{ I 1 < l_LEVEL_TN6 : bit (4) > } 

{ I 1 < l_LEVEL_TN7 : bit (4) > } 

{ null I bit** = <no string> -- Receiver backward compatible witli earlier version 

I 1 -- Additional contents for Release 1999 

{ I 1 < EGPRS BEP Link Quality IVIeasurements : 

< EGPRS BEP Link Quality IVIeasurements IE » } 
{ I 1 < EGPRS Timeslot Link Quality Measurements : 

< EGPRS Timeslot Link Quality Measurements IE »} 
{ I 1 < PFI: bit{7) > } 

< ADDITIONAL MS RAC INFORMATION AVAILABLE : bit (1) > 

< RETRANSMISSION OF PRR : bit (1) > 

{ null I bit** = < no string > -- Receiver backward compatible with earlier version 
I 1 -- Additions for REL-5 

{ I 1 { I 1 < G-RNTI extension : bit (4) > } 

< lu mode Channel Request Description : < lu mode Channel Request Description IE > > } 
{0| 1 <HFN_LSB :bit(1)>} 
{ null I bit** = <no string> -- Receiver backward compatible with earlier version 
I 1 -- Additional contents for Release 6 

{ I 1 < Extended Channel Request Description : 

< Extended Channel Request Description IE > > } 

< padding bits > } } }; 

Table 11.2.16.2: PACKET RESOURCE REQUEST information element details 

Global TFI 

This information element contains (one of) the TFI of the mobile station's uplink TBF, if available, or (one of) the TFI 
of the mobile station's downlink TBF. If no TFI is available, this field is omitted. This field is defined in sub-clause 
12.10. 

ACCESS_TYPE (2 bit field) 

This field indicates the reason for requesting the access. It shall be included only in response to a single block or Multi 

block assignment. 

bit 
2 1 
Two Phase Access Request 

1 Page Response 

1 Cell Update 

1 1 Mobility Management procedure 

TLLI / G-RNTI 

This information element is defined in sub-clause 12.16. 

MS Radio Access Capability 2 

This information element is defined in sub-clause 12.30. This information element is sent only during two phase access 
and shall not be include by MS operating in lu mode. Additionally, this information element shall be sent in one phase 
EGPRS TBF establishment procedure if ordered by the network. 
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Channel Request Description 

This information element is defined in sub-clause 12.7. If a PFI field is included in this message, it relates to the TBF 
request contained in the Channel Request Description IE. If the Extended Channel Request Description IE is included 
in this message, the value of this IE (and the PFI field) shall be ignored.Iu mode Channel Request Description 
This information element is defined in sub-clause 12.7a. If this is included, the Channel Request Description IE shall be 
coded as zeros and shall be ignored. 

Extended Channel Request Description 

This information element is defined in sub-clause 12.7b. This IE contains a request for one or more additional uplink 
TBFs and shall only be included if the mobile station and the network support multiple TBF procedures. If this IE is 
included, the Channel Request Description IE and PFI field in the message shall be ignored. 

CHANGE_MARK (2 bit field) 

This field contains the PSI2_CHANGE_MARK value stored by the mobile station's if PBCCH is present in the current 
cell. If PBCCH is not present in the current cell, this field contains the SI13_CHANGE_MARK value stored by the 
mobile station. If the mobile station does not have a valid PSI2 or SI13 change mark for the current cell, the mobile 
station shall omit this field. The coding of this field is network dependent. 

C_VALUE (6 bit field) 

This field is encoded as the binary representation of the C value as specified in 3GPP TS 45.008. 

Range to 63 

SIGN_VAR (6 bits) 

This field contains the signal variance parameter SIGN_VAR calculated by the mobile station (see 3GPP TS 45.008). 

This field is not present for TBF establishment using two phase access or for a TBF in EGPRS mode. 

bit 

654321 

OdB^ to 0.25 dB^ 

1 >0.25 dB^ to 0.50 dB^ 

10 >0.50 dB^ to 0.75 dB^ 

111110 >15.50dB^ to 15.75 dB^ 

111111 >15.75 dB^ 

I_LEVEL_TNO (4 bit field) 

I_LEVEL_TN1 (4 bit field) 

I_LEVEL_TN2 (4 bit field) 

I_LEVEL_TN3 (4 bit field) 

I_LEVEL_TN4 (4 bit field) 

I_LEVEL_TN5 (4 bit field) 

I_LEVEL_TN6 (4 bit field) 

I_LEVEL_TN7 (4 bit field) 

For element definition see sub-clause 1 1 .2.6 - Packet Downlink Ack/Nack. These fields shall not be present if they are 

included in the EGPRS Timeslot Link Quality Measurements IE. 

EGPRS BEP Link Quality Measurements IE 

This information element is defined in sub-clause 12.5.3. These fields are transferred if the data is available and if the 
fields would not cause the message to expand beyond one RLC/MAC control block and if the PACKET RESOURCE 
REQUEST is sent during on-going EGPRS concurrent TBF. 

EGPRS Timeslot Link Quality Measurements 

This information element is defined in sub-clause 12.5.4. These fields are transferred if the data is available and if the 
fields would not cause the message to expand beyond one RLC/MAC control block and if the PACKET RESOURCE 
REQUEST is sent during on-going EGPRS TBF. 

PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context relating to the resource request specified in the 
Channel Request Description IE. The PFI parameter is encoded as the contents of the PFI information element as 
defined in 3GPP TS 44.018. This field may be included if the network supports packet flow context procedures. If the 
Extended Channel Request Description IE is included in this message, the value of this field (and the Channel Request 
Description IE) shall be ignored. 
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ADDITIONAL MS RAC INFORMATION AVAILABLE (1 bit field) 

indicates that the MS will not send more information about its radio access capabilities than included in this 
message 

1 indicates that the MS will provide more information about its radio access capabilities by sending an ADDITIONAL 
MS RADIO ACCESS CAPABILITIES message, either in the next radio block allocated to the mobile station on the 
assigned PDCH, or upon a further request from the network if the mobile station was allocated only one radio block. 
This value shall not be used by MS operating in lu mode. 

RETRANSMISSION OF PRR (1 bit field) 

This field indicates whether the corresponding Packet Resource Request message is a retransmission. In case the PRR 
message is a retransmission, the message content (except this field and the address information) shall be identical to the 
one of the PRR which was sent immediately after the uplink TBF was established (and preceding any eventual request 
for resource reassignment). 

indicates that this message is an initial Packet Resource Request 

1 indicates that this message is a retransmitted Packet Resource Request: in this case the corresponding PRR message 
shall not be interpreted as a request for resource reassignment. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier for contention resolution in lu-mode. 

HFN_LSB(1 bit field) 

This field contains the least significant bit of the uplink HEN of the radio bearer for which the TEE is requested. 



11.2.17 Packet PS I Status 

This message is sent on the PACCH from the mobile station to the network to indicate which PSI messages the mobile 
station has received. 

Message type: PACKET PSI STATUS 

Direction: mobile station to network 

Table 11.2.17.1: PACKET PSI STATUS information elements 

< Packet PSI Status message content > ::= 

< GLOBAL_TFI : < Global TFI IE > > 

< PBCCH_CHANGE_MARK : bit (3) > 

< Received PSI Message List : < PSI Message List struct > > 

< Received Unknown PSI Message List : < Unknown PSI Message List struct > > 

{ null I bit** = < no string > - Receiver backward compatible witii earlier version 

I 1 - Additions for REL-6 : 

< PS_REL_REQ : bit > 

< padding bits > } ; 

< PSI Message List struct > ::= 

{ 1 < MESSAGE_TYPE : bit (6) > 

< PSIX_CHANGE_MARK : bit (2) > 
{ I 1 < PSIX_COUNT : bit (4) > 

< Instance bitmap : bit (val(PSIX_COUNT) + 1) > } } ** 

< ADDITIONAL_MSG_TYPE : bit > ; 

< Unknown PSI Message List struct > ::= 

{ 1 < MESSAGE_TYPE : bit (6) > } ** 

< ADDITIONAL MSG TYPE : bit > ; 
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Table 11.2.17.2: PACKET PSI STATUS information element details 

Global TFI (information element) 

This information element contains the TFI of the mobile station's uplink or downlink TBF.. The coding of this 

information element is defined in sub-clause 12.10. 

PBCCH_CHANGE_MARK (3 bit field) 

This field is the binary representation of the last PBCCH_CHANGE_MARK received in the PSIl message on PBCCH. 

Received PSI Message List (construction) 

This construction contains a list of supported PSI messages (see sub-clause 5.5.1.4.3). The sender of this message may 
indicate as many messages in this list as can be fit into the message. Messages are listed by message type in descending 
order of priority. If there are more PSI messages than can be indicated in this list, the presence of additional message 
type(s) shall be indicated at the end of the list. 

If the sender of this message has received a PSI message which is part of a consistent set of PSI messages (see 
5.5.2.1.4), the Instance Bitmap may indicate which instances of this message type that have been received. 

Under certain circumstances, see sub-clause 5.5.1.4.3, the sender of this message may use this construction to indicate 
the message type of a PSI message that has not been received. In that case, the corresponding Instance Bitmap field 
shall be included. The PSIX_CHANGE_MARK field, PSIX_COUNT field and the one element of the Instance Bitmap 
field shall all be set to the value '0'. 

Received Unknown PSI Message List (construction) 

This construction contains a list of message types that are received on PBCCH, which are either unknown or not 
recognized as supported PSI message types. The sender of this message may indicate as many messages in this list as 
can be fit into the message following the Received PSI Message List. Messages are listed by message type in the 
inverse order of reception, starting with the most recently received message type. If there are more messages than can 
be indicated in this list, the presence of additional message type(s) shall be indicated at the end of the list. 

MESSAGE_TYPE (6 bit field) 

This field is the binary representation of the message type (see sub-clause 11.2.0.1). 

PSIX_CHANGE_MARK (2 bit field) 

This field is the binary representation of the PSI change mark parameter received for a certain PSI message type. 

Range: to 3. 

PSIX_COUNT (4 bit field) 

This field is the binary representation of the PSI count parameter received for a certain PSI message type. This field 

indicates the length of the corresponding Instance bitmap field and shall be provided only if the corresponding Instance 

bitmap field is provided in the message. 

Range: to 7 or to 15, depending on message type. 

Instance bitmap (1 - 16 bit field) 

This field is a bitmap indicating which instances of a certain message type that are received within a consistent set of 
PSI messages. This field shall be included when a sub-set of these messages has been received. This field shall not be 
included when the complete set of these messages has been received. 

The most significant bit of this bitmap (bit N) refers to the message instance with the PSI index parameter = N-1, where 
N is the number of instances of the particular message type (PSI count + I). The least significant bit of this bitmap 
(bit 1) refers to the message instance with the PSI index parameter = 0. Each bit position is coded: 

Message instance is not received; 

1 Message instance is received. 

ADDITIONAL_MSG_TYPE (1 bit field) 

No additional message type is present. 

1 Additional message type(s) are available, but this information does not fit into the message. 
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PS_REL_REQ (1 bit field) 

This field indicates whether the mobile station requests the release of the RR connection and packet resources. This 
field may only be set to "1" in certain cases, see 3GPP TS 44.018. This field shall always be present in the message 
when the enhanced DTM CS release procedure is ongoing. 

The mobile station does not request the release of the RR connection and packet resources. 

1 The mobile station requests the release of the RR connection and packet resources. 



1 1 .2.1 7a Packet Serving Cell Data 

This optional message is sent by the network on the PACCH to provide system information broadcast on the BCCH 
(respectively PBCCH to a mobile station. For example, several instances of this message may be sent by the network in 
a cell supporting PACKET SI STATUS (respectively PACKET PSI STATUS) following the request for acquisition of 
system information by a mobile station. This message shall not be segmented across more than one RLC/MAC control 
block. If not all information fits into one instance of the PACKET SERVING CELL DATA message, the message can 
be repeated. 

Message type: PACKET SERVING CELL DATA 

Direction: network to mobile station 

Classification: non-distribution message 

Table 11.2.17a.1: Packet Serving Cell Data information elements 

< Packet Serving Cell Data message content > ::= 

< PAGE_MODE : bit (2) > 
{ < Global TFI : < Global TFI IE > > 
{ < spare : bit (4) > 

< CONTAINERJNDEX : bit (5) > 

< CONTAINER : < Container repetition struct > > 

< padding bits > 

! < Non-distribution part error : bit (*) = < no string > > } 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

< Container repetition struct > ::= 

{ 

{ < PD : bit (3) > 

< CD_LENGTH : { bit (5) exclude 00000 exclude 11 11 1 } > 

< CONTAINER_DATA : octet (val(CD_LENGTH)) > - Final container segment. Next container foiiows. 

I < PD : bit (3) > 

< CD_LENGTH : { bit (5) := 11 1 1 1 } > 

< CONTAINER_DATA : octet **>}** - Container continued in next message. 

{ < spare bit (3) > ~ Repetition continues until: 

< CD_LENGTH : { bit (5) := 00000 } > } -A) val(CD_LENGTH) = or 

} // ; - B) end of PSCD message. 



Table 11.2.17a.2: Packet Serving Cell Data information element details 

The Packet Serving Cell Data message consists of up to 32 instances and contains serving cell system information 
messages from the BCCH or from the PBCCH or from both. Each container repetition struct contains information from 
one or more SI/PSI message. One SI/PSI message can be distributed over more than one instance. 

A container can only refer to the serving cell. 
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PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

PD (3 bit field) 

This field contains a protocol discriminator and indicates the origin of the contained message. 

Bit 

2 1 

BCCH (LAPDm); 

1 PBCCH (RLC/MAC); 

10 Reserved; If received the contents of the container shall be discarded. 



Ill Reserved; If received the contents of the container shall be discarded. 

CD_LENGTH (5 bit field) 

This field indicates the number of CONTAINER DATA octets that forms a specific SI/PSI message and is coded as 

shown below. 

Bit 

5432 1 

No CONTAINER DATA follows; Spare padding is used to fill the rest of the message; 

1 CONTAINER DATA length = 1 octet; 

10 10 CONTAINER DATA length = 18 octets; 

11111 The remaining portion of the Packet Serving Cell Data message is used by the associated CONTAINER 
DATA. The message continues in a subsequent instance of the Packet Serving Cell Data message, in the 
next CONTAINER DATA with the same Protocol Discriminator value as the current one. 

All other values reserved. If a reserved value is received the contents of the container shall be discarded. 

CONTAINER_DATA(n*8 bits) 

The concatenation of one or several CONTAINER_DATA octets forms the actual contents, specific to the SI/PSI 

messages. 

If the contained system information messages are copied from the BCCH the information contained in the Packet 
Serving Cell Data message shall exclude the following information elements from the beginning of the messages: L2 
Pseudo Length; RR management Protocol Discriminator and Skip Indicator. 

If the contained system information messages are copied from the PBCCH the information contained in the Packet 
Serving Cell Data message shall include the complete PSI message. 

Extra octets of padding bits at the end of the SI/PSI messages may be excluded. 



11. 2. 17b Packet SI Status 

This message is sent on the PACCH from the mobile station to the network to indicate which SI messages the mobile 
station has received. 

Message type: PACKET SI STATUS 

Direction: mobile station to network 
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Table 11. 2.1 7b.1 : PACKET SI STATUS information elements 



< Packet SI Status message content > ::= 

< GLOBAL TFI : < Global TFI IE > > 

< BCCH_CHANGE_MARK : bit (3) > 

< Received SI Message List : < SI Message List struct > > 

< Received Unl^nown SI Message List : < Unknown SI Message List struct > > 




{ null 1 bit** = < no string > - Receiver backward compatible witli earlier version 
1 1 -- Additions for REL-6 : 

< PSCSI SUPPORT : bit > 

< PS_REL_REQ : bit > 

< padding bits > } ; 




< SI Message List struct > ::= 

{ 1 < SI_MESSAGE_TYPE : bit (8) > 

{ < MESS_REC : bit (2) == 00 >< null > -- Message type supported but not received 

1 < MESS_REC : bit (2) == 01 >< null > -- Message type supported and received, single instance 

< MESS REC : bit (2) == 10 > -- Message type supported and partially received, multiple instances 

< SIX CHANGE MARK : bit (3) > 

< SIX COUNT : bit (4) > 

< Instance bitmap : bit (val(SIX_COUNT) + 1) > 

1 < MESS_REC : bit (2) == 1 1 > -- Message type supported and completely received, multiple 

< SIX_CHANGE_MARK : bit (3) > } 

\ ** r\ 


i 

< ADDITIONAL_MSG_TYPE : bit > ; 






< Unknown SI Message List struct > ::= 

{ 1 < SI MESSAGE TYPE : bit (8) > } ** 
< ADDITIONAL MSG TYPE : bit > ; 







Table 11. 2.17b.2: PACKET SI STATUS information element details 



Global TFI (information element) 

This information element contains the TFI of the mobile station's uplink or downlink TBF. The coding of this 

information element is defined in sub-clause 12.10. 

BCCH_CHANGE_MARK (3 bit field) 

This field is the binary representation of the last BCCH_CHANGE_MARK received in the SI13 message on BCCH or 

PACCH. 

Received SI Message List (construction) 

This construction contains a list of supported SI messages (see sub-clause 5.5.1.4.3). The sender of this message may 
indicate as many messages in this list as can be fit into the message. Messages are listed by message type in descending 
order of priority. If there are more SI messages than can be indicated in this list, the presence of additional message 
type(s) shall be indicated at the end of the list. 

If the sender of this message has received an SI message which is part of a consistent set of SI messages (see sub- 
clause 5.5.2.1.4), the Instance Bitmap may indicate which instances of this message type that have been received. 

Received Unknown SI Message List (construction) 

This construction contains a list of message types that are received on BCCH, which are either unknown or not 
recognised as supported SI message types. The sender of this message may indicate as many messages in this list as can 
be fit into the message following the Received SI Message List. Messages are listed by message type in the inverse 
order of reception, starting with the most recently received message type. If there are more messages than can be 
indicated in this list, the presence of additional message type(s) shall be indicated at the end of the list. 

SI_MESSAGE_TYPE (8 bit field) 

This field is the binary representation of the message type of the indicated SI message (see 3GPP TS 24.007 and 

3GPPTS 44.018). 
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MESS_REC (2 bit field) 

This field indicates for each message type that is supported by the mobile station whether one or more instances of the 

message have been received. The field is coded: 

Bit 

2 1 

The message type is supported but not received; 

1 The message type is supported and received; this type of SI message does not exist in multiple instances; 

1 The message type is supported and instances of the message with the indicated change mark are partially 

received; 

1 1 The message type is supported and all instances of the message are received with the indicated change mark. 

SIX_CHANGE_MARK (3 bit field) 

This field is the binary representation of the SI change mark parameter received for a certain SI message type, except 
for the SI2ter, the SI2quater and the SI15 message types. For the SI2ter, SI2n, SI18, SI19 and SI20 messages, the range 
is: to 3. For the SI2quater and SI15 messages, the range is: to 7. 

For the SI2ter message type, the three bits are used according to the following principles: 

SI2ter 

Bit 

321 

- X Bit 1 : SI2ter_3G_CHANGE_MARK 

X - Bit 2: SI2ter_MP_CHANGE_MARK. 

For the SI2quater message type, the mobile station shall include the latest received values of the BA_IND, 
3G_BA_IND and MP_CHANGE_MARK fields. The field is coded as follows: 

Bit 
321 

- - X Bit 1 : MP_CHANGE_MARK 

- X - Bit 2: 3G_BA_IND 
X - - Bit 3: BA_IND 

For the SI15 message type, the mobile station shall include the three least significant bits of the DM_CHANGE_MARK 
parameter (i.e., DM_CHANGE_MARK modulo 8). 

SIX_COUNT (4 bit field) 

This field is the binary representation of the SI count parameter received for a certain SI message type. This field 
indicates the length of the corresponding Instance bitmap field and shall be provided only if the corresponding Instance 
bitmap field is provided in the message. 

For SI18, SI19 and SI20 messages, this field shall be set to 7 if present. 

For the SI15 message the range is to 3. 

For the SI2ter message the range is to 7. 

For the SI2quater message the range is to 15. 

For the SI2n message the range is to 15. 

Instance bitmap (1 - 16 bit field) 

This field is a bitmap indicating which instances of a certain message type that are received within a consistent set of SI 
messages. This field shall be included when a sub-set of these messages has been received. This field shall not be 
included when the complete set of these messages has been received. 

The most significant bit of this bitmap (bit N) refers to the message instance with the SIX index parameter = N-1, where 
N is the number of instances of the particular message type (SIX count + 1). The least significant bit of this bitmap 
(bit 1) refers to the message instance with the SI index parameter = 0. Each bit position is coded: 

Message instance is not received; 

1 Message instance is received. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 267 ETSI TS 144 060 V6.28.0 (2010-03) 

ADDITIONAL_MSG_TYPE (1 bit field) 

No additional message type is present. 

1 Additional message type(s) are available, but this information does not fit in to the message. 

PSCSI_SUPPORT (1 bit field) 

PACKET SERVING CELL SI message not supported 

1 PACKET SERVING CELL SI message supported 

The MS shall set the PSCSI_SUPPORT bit to "1" in this revision of the specification. This field shall always be present 
in the PACKET SI STATUS message. If not present, '0' shall be assumed by the receiver 

PS_REL_REQ (1 bit field) 

This field indicates whether the mobile station requests the release of the RR connection and packet resources. This 
field may only be set to "1" in certain cases, see 3GPP TS 44.018. This field shall always be present in the message 
when the enhanced DTM CS release procedure is ongoing. 

The mobile station does not request the release of the RR connection and packet resources. 

1 The mobile station requests the release of the RR connection and packet resources. 



1 1 .2.1 7c Packet Serving Cell SI 



This optional message is sent by the network on the PACCH to provide a SYSTEM INFORMATION message 
broadcast on the BCCH. For example, several instances of this message may be sent by the network in a cell supporting 
PACKET SI STATUS following the request for acquisition of system information by a mobile station. This message 
shall not be segmented across more than one RLC/MAC control block. 

Message type: PACKET SERVING CELL SI 

Direction: network to mobile station 

Classification: distribution message 

Table 11.2.17c.1: Packet Serving Cell SI information elements 

< Packet Serving Cell SI message content > ::= 

< PAGE_MODE : bit (2) > 

< CONTAINER_DATA : octet ** > 

< padding bits >z 

! < Distribution part error : bit (*) = < no string > > ; 



Table 11.2.17c.2: Packet Serving Cell SI information element details 

The Packet Serving Cell SI message contains a serving cell SYSTEM INFORMATION message from the BCCH. 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

CONTAINER_DATA(n*8 bits) 

The CONTAINER_DATA octets forms the actual SI message content. The information contained in the Packet Serving 
Cell SI message shall exclude the following information elements from the beginning of the SI message: L2 Pseudo 
Length; RR management Protocol Discriminator and Skip Indicator. 

Extra octets of padding bits at the end of the SI message may be excluded. 
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11 .2.1 8 Packet System Information Type 1 



This message is sent by the network on the PBCCH or PACCH giving information for Cell selection, for control of the 
PRACH, for description of the control channel(s) and optional global power control parameters. This message shall not 
be segmented across more than one RLC/MAC control block by using the procedures specified in sub-clause 9. 1 . 12a. 
Special requirements for the transmission of this message apply on the PBCCH, see 3GPP TS 45.002. 

Message type: PACKET SYSTEM INFORMATION TYPE 1 

Direction: network to mobile station 

Classification: distribution message 

Table 11.2.18.1: PSI1 information elements 

< PSI1 message content > ::= 

< PAGE_MODE : bit (2) > 

< PBCCH_CHANGE_MARK : bit (3) > 

< PSI_CHANGE_FIELD : bit (4) > 

< PSI1_REPEAT_PERI0D : bit (4) > 

< PSLCOUNT_LR : bit (6) > 

{ I 1 < PSI_COUNT_HR : bit (4) > } 

< MEASUREMENT_ORDER: bit (1) > 

< GPRS Cell Options : < GPRS Cell Options IE > > 

< PRACH Control Parameters : < PRACH Control Parameters IE > > 

< PCCCH Organization Parameters : < PCCCH Organization Parameters IE > > 

< Global Power Control Parameters : < Global Power Control Parameters IE > > 

< PSLSTATUSJND : bit > 

{ null I -- Receiver backward compatible witli eariier reiease 

I 1 -- Additions in release 99 : 

< MSCR : bit > 

< SGSNR : bit > 

< BANDJNDICATOR : bit > 

{null I -- Receiver bacl<ward compatible witli earlier release 

I 1 -- Additions in Rel-6 : 

{ I 1 < LB_MS_TXPWR_MAX_CCH : bit (5) > } 

< padding bits > } } 

! < Distribution part error : bit (*) = < no string > > ; 

Table 11.2.18.2: PSI1 information element details 

GPRS Cell Options 

This information element is defined in sub-clause 12.24 

Global Power Control Parameters 

This information element is defined in sub-clause 12.9. 

MEASUREMENT ORDER (1 bit field) 

The MEASUREMENT ORDER field indicates if set = that the mobile station is in control of the cell re-selection in 

both packet idle mode and packet transfer mode and that the mobile station shall not send any measurement reports to 

the network (= NCO in 3GPP TS 45.008). It also indicates that the Optional PSI5 message is not broadcast. 

If set = 1 the mobile station shall send measurement reports for cell re-selection to the network. Further cell re-selection 

and measurement details are included in the PSI5 message. 

PAGE_MODE (2 bit field) 

This field describes which type of page mode used, i.e. either normal paging, extended paging, paging reorganization or 
same as before from the previous page mode. The mobile station shall ignore this field if the message is received on the 
PACCH. Coding of this field is defined in 3GPP TS 44.018. 

PBCCH_CHANGE_MARK (3 bit field) 

The PBCCH_CHANGE_MARK field is a 3 bit counter incremented with one each time information has been changed 

in one or more of the broadcast PSI2-PSIn messages on PBCCH (n>2). 
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PSI_CHANGE_FIELD (4 bit field) 

The PSI_CHANGE_FIELD is a 4 bit value reflecting which PSI message or group of instantiated PSI message was 
most recent updated when the PBCCH_CHANGE_MARK was last incremented. If more than one PSI message or 
group of instantiated PSI message were changed at the same time, the PSI_CHANGE_FIELD indicates unspecified 
updates. Range to 15. 

Bit 

4321 

Update of unspecified PSI message(s); 

1 Unknown 

10 PSI2 updated 

11 PSI3/PSI3bis/PSI3ter/PSI3quater updated 

10 Unknown — This value was allocated in an earlier version of the protocol and shall not be used 

10 1 PSI5 updated 

110 PSI6 updated 

111 PSI7 updated 

10 PSI8 updated 

All other values shall be interpreted as 'Update of unknown SI message type'. 

PSIl_REPEAT_PERIOD (4 bit field) 

This field is the binary representation of the PSIl_REPEAT_PERIOD parameter value minus one, see 

3GPP TS 45.002. The field is coded according to the following table: 



Bit 




4321 




0000 


PSIl REPEAT PERIOD = 1 


0001 


PSIl REPEAT PERIOD = 2 



1111 PSIl_REPEAT_PERIOD = 16 

PSI_COUNT_LR (6 bit field) 

This field is the binary representation of the PSI_COUNT_LR parameter, see 3GPP TS 45.002. The field is coded 

according to the following table: 



Bit 




654321 




000000 


PSI COUNT LR = 


000001 


PSI_COUNT_LR = 1 


111111 


PSI COUNT LR = 6 



PSI_COUNT_HR (4 bit field) 

This field is the binary representation of the PSI_COUNT_HR parameter value minus one, see 3GPP TS 45.002. If 
PSI_COUNT_HR is not included in PSIl message, the default value PSI_COUNT_HR = applies. The field is coded 
according to the following table: 

Bit 

4321 

PSI_COUNT_HR = 1 

1 PSI_COUNT_HR = 2 

1111 PSI_COUNT_HR = 16 

PCCCH Organization Parameters 

This information element is defined in sub-clause 12.25 

PRACH Control Parameters 

This information element is defined in sub-clause 12.14. 

PSI_STATUS_IND (1 bit field): 

The network does not support the PACKET PSI STATUS message; 

1 The network supports the PACKET PSI STATUS message. 
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MSCR, MSC Release (1 bit field): 

The MSC is Release '98 or older 

1 The MSC is Release '99 onwards 

SGSNR, SGSN Release (1 bit field) 

The SGSN is Release '98 or older 

1 The SGSN is Release '99 onwards 

BANDJNDICATOR (1 bit field) 

See 3GPP TS 45.005 for definition of this field, which is coded as follows: 

ARFCN indicates 1 800 band 

1 ARFCN indicates 1900 band 

LB_MS_TXPWR_MAX_CCH (5 bit field) 

The LB_MS_TXPWR_MAX_CCH field is coded as the binary representation of the 'power control level' in 

3GPP TS 45.005 corresponding to the maximum TX power level a mobile station may use when accessing on a packet 

control channel. This value shall be used by the mobile station according to 3GPP TS 45.008. 



NOTE 1 : The MSC Release bit indicates the version of the MSC specific protocols and is not applicable to access 
stratum protocols. 

NOTE 2: The SGSN Release bit indicates the version of the SGSN specific protocols and is not applicable to access 
stratum protocols. 

11 .2.1 9 Packet System Information Type 2 

This message is sent by the network on PBCCH and PACCH giving information of reference frequency lists, cell 
allocation, GPRS mobile allocations and PCCCH descriptions being used in the cell. Special requirements for the 
transmission of this message apply on PBCCH, see 3GPP TS 45.002. 

PSI2 also contains Non-GPRS cell options applicable for non-packet access. 

This message shall not be segmented across more than one RLC/MAC control block by using the procedures specified 
in sub-clause 9.1.12a. A consistent set of this message type is required to completely decode the information (see sub- 
clause 5.5.2.1.4). 

Message type: PACKET SYSTEM INFORMATION TYPE 2 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.19.1: PSI2 information elements 

< PSI2 message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI2_CHANGE_MARK : bit (2) > 

< PSI2JNDEX : bit (3) > 

< PSI2_C0UNT : bit (3) > 

{ { I 1 < Cell Identification : < Cell Identification IE > > } 

{ I 1 < Non GPRS Cell Options : < Non GPRS Cell Options IE > > } 

< Reference Frequency Lists : < Reference Frequency Lists struct > > 

< Cell Allocation : < Cell Allocation Lists struct > > 

< GPRS Mobile Allocations : < GPRS IVIobile Allocations Lists struct > > 

< PCCCH Description : < PCCCH Description Lists struct > > 
{ null I bit** = < no string > 

I 1 -- Release 1999 additions: 

{ I 1 < COMPACT Control Information : < COIVIPACT Control Info struct > > } 
{ I 1 < Additional PSI Messages : < Additional PS! Messages struct > > } 
< padding bits >}}//-- truncation at end of message ailowed, bits '0' assumed 
! < Distribution part error : bit (*) = < no string > > ; 

< Reference Frequency Lists struct > ::= { 1 < Reference Frequency struct > } ** 0; 

< Reference Frequency struct >::= 

< RFL_NUMBER : bit (4) > 

< Length of RFL contents : bit (4) > 

< RFL contents : octet (val(Length of RFL contents) + 3) > ; 

< Cell Allocation Lists struct > ::= { 1 < Cell Allocation struct > } ** ; 

< Cell Allocation struct > ::= 

< RFL_NUMBER : bit (4) > ; 

< GPRS IVIobile Allocations Lists struct > ;:= { 1 < GPRS Mobile Allocations struct > } ** ; 

< GPRS Mobile Allocations struct > ::= 

< MA_NUMBER : bit (4) > 

< GPRS Mobile Allocation : < GPRS Mobile Allocation IE > > ; 

< PCCCH Description Lists struct > ::= { 1 < PCCCH Description struct > } ** ; 

< PCCCH Description struct > ::= 

< TSC : bit (3) > 

{ < Non-hopping PCCCH carriers : < Non-Hopping PCCCH Carriers Lists struct > > 
I 1 < MA_NUMBER : bit (4) > 

< Hopping PCCCH carriers : < Hopping PCCCH Carriers Lists struct > > } ; 

< Non-hopping PCCCH Carriers Lists struct > ::= { 1 < Non-Hopping PCCCH Carriers struct > } ** ; 

< Non-Hopping PCCCH Carriers struct > ::= 

<ARFCN:bit(10)> 

< TIMESLOT_ALLOCATION : bit (8) > ; 

< Hopping PCCCH Carriers Lists struct > ::= { 1< Hopping PCCCH Carriers struct > } ** ; 

< Hopping PCCCH Carriers struct > ::= 

< MAIO : bit (6) > 

< TIMESLOT_ALLOCATION : bit (8) > ; 

< COMPACT Control Info struct > ::= 

< Large Cell Operation : bit (1) > 

{0 I 1 <Number of Idle Blocks : <Number of Idle Blocks struct> >} 
{0 I 1 <N_CCCH_NH : bit (4) >} ; 
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<Number of Idle Blocks struct> 



{0 |1 { < NIB_CCCH_0 
{0 |1 { < NIB_CCCH_1 
{0 |1 { < NIB_CCCH_2 
{0 |1 { < NIB_CCCH_3 



bit (4) > } } 
bit (4) > } } 
bit (4) > } } 
bit (4) > } } 



< Additional PSI Messages struct > ::= 

< NON_GSMJNFORMATION : bit(2) 

< PSI8_BR0ADCAST : bit (1) > 

< PSI3ter_BR0ADCAST : bit (1) > 

< PSI3quater_BR0ADCAST : bit (1) : 



Table 11.2.19.2: PSI2 information element details 



PAGE_MODE (2 bit field) 

This field describes which type of page mode used, i.e. either normal paging, extended paging, paging reorganization or 
same as before from the previous page mode. The mobile station shall ignore this field if the message is received on the 
PACCH. Coding of this field is defined in 3GPP TS 44.018 

PSI2_CHANGE_MARK (2 bit field) 

This field is the binary representation of the PSI change mark parameter identifying a consistent set of PSI2 messages. 

Range: to 3. 

PSI2_INDEX (3 bit field) and PSI2_COUNT (3 bit field) 

These fields are the binary representation of the PSI index and PSI count parameters associated with the PSI2 message. 

Cell Identification 

This information element is defined in sub-clause 12.23. This field shall be present in at least one instance of PSI2 and 
may appear only once in a complete set of PSI2 messages. 

Non GPRS Cell Options 

This field is defined in sub-clause 12.27. 

This field shall be present in at least one instance of PSI2. 

Reference Frequency Lists (construction) 

This construction is the representation of the reference frequency lists provided in an instance of the PSI2 message. An 

RFL_NUMBER field preceding each reference frequency list (RFL) identifies the RFL. 

Cell Allocations (construction) 

This construction is a representation of the cell allocation (CA) defined for the cell. The set of radio frequency channels 

contained in the referenced RFLs in this construction defines the cell allocation. 

GPRS Mobile Allocations (construction) 

This construction is the representation of the GPRS mobile allocations provided in an instance of the PSI2 message. An 
MA_NUMBER field preceding each GPRS mobile allocation identifies the GPRS mobile allocation. The receiver shall 
disregard a GPRS mobile allocation provided in this message that is identified by MA_NUMBER = 14 or 15. 
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PCCCH Description (construction) 

This construction is a representation of the timeslots carrying PCCCH in the cell and their frequency configurations. 
The training sequence code (TSC) preceding each list of PCCCH carriers in the PCCCH description shall be used for 
the timeslots selected for PCCCH on those PCCCH carriers. The TSC that is used for the timeslot also carrying PBCCH 
shall equal the TSC used for the PBCCH in the cell. 

The number of timeslots carrying PCCCH in the cell is denoted KC. This is also the implicit value of the parameter 
BS_PCC_CHANS, see 3GPP TS 45.002. The range for KC is 1 to 16 if PBCCH (and PCCCH) is present in the cell. 
(KC = if PBCCH is not present in the cell.) 

The mapping of the PCCCH_GROUPs (numbered from to KC-1) starts with the lowest numbered PCCCH_GROUP, 
which is mapped on the lowest numbered timeslot carrying PCCCH on the first (non-hopping or hopping) PCCCH 
carrier appearing in this construction. The next higher numbered PCCCH_GROUP is mapped on the next (if any) 
higher numbered timeslot carrying PCCCH on the same carrier, and so on. When all timeslots carrying PCCCH on the 
first carrier have been used, the next higher numbered PCCCH_GROUP is mapped on the lowest numbered timeslot 
carrying PCCCH on the next PCCCH carrier appearing in this construction, and so on. The highest numbered 
PCCCH_GROUP is mapped on the highest numbered timeslot carrying PCCCH on the last PCCCH carrier appearing 
in this construction. 

RFL_NUMBER (4 bit field) 

This field is the binary identification of an RFL provided in this message or the binary reference to such. 

Range: to 15. 

RFL contents (variable length octet string) 

This variable length octet string is the representation of a set of radio frequency channels defining an RFL provided in 
the PSI2 message. The encoding of the octet string is defined by the value part of the type 4 information element 
Frequency List, defined in 3GPP TS 44.018. The allowed formats of the Frequency List information element are the bit 
map 0, 1024 range, 512 range, 256 range, 128 range and variable bit map formats. 

MA_NUMBER (4 bit field) 

This field is the binary identification of a GPRS Mobile Allocation provided in this message or the binary reference to 

such. 

Range: to 13. (MA_NUMBER = 14 and 15 shall not be used in this message.) 

GPRS Mobile Allocation (information element) 

The GPRS Mobile Allocation information element is defined in sub-clause 12.10a. 

TSC (3 bit field) 

This field is the binary representation of the training sequence code, see 3GPP TS 45.002. 

Range: to 7. 

ARFCN (10 bit field) 

This field is the binary representation of the absolute radio frequency channel number (ARFCN) defined in 

3GPP 45.005. 

Range to 1023. 

MAIO (6 bit field) 

This field is the binary representation of the mobile allocation index offset (MAIO), see 3GPP TS 45.002. 

Range: to 63. 

TIMESLOT_ALLOCATION (8 bit field) 

This field indicates which timeslot are assigned as PCCCH. This field is coded as defined in sub-clause 12.18. . Note 
that for a CPCCCH this information shall be ignored by the MS, the CPCCCH is rotating between odd timeslots and not 
allocated to a specific timeslot, see 3GPP TS 45.002. 

Large Cell Operation (LARGE_CELL_OP) 

If this bit is set to one, the cell is in large cell operation mode (see 3GPP TS 45.002). 

This cell is a nominal size cell 

1 This cell is a large cell 
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NIB_CCCH_0 (4 bit field) 

This field is the binary representation of the number of radio blocks that shall remain idle in time group for blocks 
associated with CPBCCH and CPCCCH (see 3GPP TS 45.002). If this information element is not present the value 
shall be used. Note that this information element shall not be present for the serving cell time group (e.g. if the serving 
cell time group is time group zero, this information element is not present, but if the serving cell time group is time 
group one this information element is present). 

NIB_CCCH_1, NIB_CCCH_2, NIB_CCCH_3 

Defined exactly as NIB_CCCH_0, except applied to time group 1, 2, and 3 respectively. 

N_CCCH_NH (4 bit field) 

This field is the binary representation of the amount of non-hopping blocks on control channels (see 3GPP TS 45.002). 

Range 1 to 11 . 

Additional PSI messages struct 

If any of the PSI messages named in this structure are broadcast in the cell, this field shall be present in at least one 
instance of PSI2 and may appear only once in a complete set of PSI2 messages. 

NON_GSM_INFORMATION (2 bit field) 

This field indicates whether non-GSM information is broadcast on the cell and specifies the messages that are used for 
this purpose. If this field indicates that both PSI6 and PSI7 are broadcast on the cell, these messages shall be broadcast 
within different repetition rate groups (see 3GPP TS 45.002). 

Bit 

2 1 

non-GSM information is not broadcast on the cell 

1 non-GSM information is broadcast on the cell in PSI6 message 

1 non-GSM information is broadcast on the cell in PSI7 message 

1 1 non-GSM information is broadcast on the cell in PSI6 and PSI7 messages 

PSI8_BROADCAST (1 bit field) 

PSI8 is not broadcast on the cell 

1 PSI8 is broadcast on the cell 

PSI3ter_BROADCAST (1 bit field) 

PSBter is not broadcast on the cell 

1 PSBter is broadcast on the cell 

PSI3quater_BROADCAST (1 bit field) 

PSBquater is not broadcast on the cell 

1 PSBquaer is broadcast on the cell 



1 1 .2.1 9.1 Reference Frequency Lists in PSI2 

A Reference Frequency Lists construction may be included in each instance of the PSI2 message. The presence of 
reference frequency lists (RFLs) is optional. RFLs shall be provided as required for the decoding of GPRS mobile 
allocations and cell allocation. 

1 1 .2.1 9.2 Cell Allocation in PSI2 

A Cell Allocation construction shall not be included in more than one instance of the PSI2 message within the 
consistent set of PSI2 messages. The presence of a Cell Allocation construction is optional. It shall be provided as 
required for the decoding of GPRS mobile allocations and for the support of GPRS mobile stations which may access 
the network in dedicated, group receive and group transmit modes, see 3GPP TS 44.018. 

1 1 .2.1 9.3 GPRS Mobile Allocation in PSI2 

A GPRS Mobile Allocations construction may be included in each instance of the PSI2 message. The presence of GPRS 
mobile allocations is optional. The GPRS mobile allocations shall be provided as required for determining the 
frequency configuration of PDCHs. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 275 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

1 1 .2.1 9.4 PCCCH Description 

A PCCCH Description construction shall be included in one and only one instance of the PSI2 message within the 
consistent set of PSI2 messages. 

11.2.19.5 Abnormal cases 

If the receiver detects any violation against the rules for the appearance of the different constructions defined for this 
message within the consistent set of this message type, it may regard the contents of these messages as invalid. 

1 1 .2.20 Packet System Information Type 3 

This message is sent by the network on the PBCCH or PACCH giving information of the BCCH allocation 
(BA(GPRS)) in the neighbour cells and cell selection parameters for serving cell and non-serving cells. This message 
shall not be segmented across more than one RLC/MAC control block by using the procedures specified in sub- 
clause 9.1.12a. Special requirements for the transmission of this message apply on the PBCCH, see 3GPP TS 45.002. 

Message type: PACKET SYSTEM INFORMATION TYPE 3 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.20.1: PSI3 information elements 

< PSI3 message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI3_CHANGE_MARK : bit (2) > 

< PSI3_BIS_C0UNT : bit (4) > 

< Serving Cell parameters : < Serving Cell params struct > > 

< General Cell Selection parameter : < Gen Cell Sel struct > > 

< Neighbour Cell parameters : { 1 < Neighbour Cell params struct > } ** > 
{ null I bit** = < no string > 

I 1 -- Release 1998 additions: 

< Serving Cell LSA ID information : < LSA ID information struct > > 
{ I 1 < LSA Parameters :< LSA Parameters IE » } 

{ null I bit** = < no string > 

I 1 -- Release 1999 additions: 

0-- The values '01', '10' and '1 1 ' were allocated in an earlier version of the protocol 
- and shall not be used. 

{ I 1 < COMPACT Information : < COMPACT Information struct > > } 

- The value '1 ' was used in an earlier version of the protocol and shall not be used. 
{ null I bit** = < no string > 
I 1 - R4 additions: 

{ I 1 < CCN Support Description : < CCN Support Description struct » } 
{ null I bit** = < no string > 
I 1 - REL-5 additions: 

< CELL BAR QUALIFY 3 : bit (2) > - Serving cell barring status. 

< lu Mode Neighbour Cell Parameters : { 1 < lu Mode Neighbour Cell params struct > } ** > 

-Supplementary information for dual lu mode and A/Gb mode capable 
cells 

< lu mode Only Neighbour Cell Parameters : { 1 < lu mode Only Neighbour Cell params struct > } ** > 

< padding bits > } }}} 

! < Distribution part error : bit (*) = < no string > > ; 

< Serving Cell params struct > ::= 

< CELL_BAR_ACCESS_2 : bit > 

< EXC_ACC : bit > 

< GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_MAX_CCH : bit (5) > 

{ I 1 < HCS Serving Cell parameters : < HCS struct > > } 

< MULTIBAND_REPORTING : bit (2) >; 

< HCS struct > ::= 

< PRIORITY_CLASS : bit (3) > 

< HCS_THR : bit (5) > ; 

< Gen Cell Sel struct > ::= 

< GPRS_CELL_RESELECT_HYSTERESIS : bit (3) > 
<C31_HYST:bit{1)> 
<C32_QUAL:bit(1)> 

1 - The value '0' was used in an earlier version of the protocol and shall not be used. 

{ I 1 < T_RESEL : bit (3) > } 

{ I 1 < RA_RESELECT_HYSTERESIS : bit (3) > } ; 

< Neighbour Cell params struct > ::= 

< START_FREQUENCY : bit (10) > 

< Cell selection params : < Cell Selection struct > > 

< NR_OF_REMAINING_CELLS : bit (4) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit (1 + val{FREQ_DIFF_LENGTH)) > 

< Cell Selection Params : <Cell Selection struct» } * (val{NR_OF_REMAINING_CELLS)) ; 
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< Cell Selection struct > ::= 

< BSIC : bit (6) > 

< CELL_BAR_ACCESS_2 : bit > 

< EXC_ACC : bit > 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

{ I 1 < GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_MAX_CCH : bit (5) > } 

{ I 1 < GPRS_TEMPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TIME : bit (5) > } 

{ I 1 < GPRS_RESELECT_OFFSET : bit (5) > } 

{ I 1 < HCS params : < HCS struct > > } 

{ I 1 < SI13 PBCCH Location : < S113 PBCCH Location struct > > } ; 

< SI13 PBCCH Location struct > ::= 

{ < SI13_L0CATI0N : bit (1) > 
I 1 < PBCCH_LOCATION : bit (2) > 

< PSI1_REPEAT_PERI0D : bit (4) > } ; 

< LSA ID information struct > ::= 

{ 1 { < LSAJD : bit (24) > 

I 1 < ShortLSAJD : bit (1 0) > } } ** ; 

< COMPACT Information struct > : := 

<Cell Identification : Cell identification IE> 

{ 1 < COIVIPACT Neighbour Cell params struct > } ** ; 

< COMPACT Neighbour Cell params struct > ::= 

< START_FREQUENCY : bit (10) > 

< COMPACT Cell selection params : < COMPACT Cell Selection struct > > 

< NR_OF_REMAINING_CELLS : bit (4) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit (1 + val{FREQ_DIFF_LENGTH)) > 

< COMPACT Cell selection params : < COMPACT Cell Selection struct > > } 

* (val(NR_OF_REMAINING_CELLS)); 

< COMPACT Cell Selection struct > ::= 

< BSIC : bit (6) > 

< CELL_BAR_ACCESS_2 : bit > 

< EXC_ACC : bit > 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

{ I 1 < GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_MAX_CCH : bit (5) > } 
{ I 1 < GPRS_TEMPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TIME : bit (5) > } 

{ I 1 < GPRS_RESELECT_OFFSET : bit (5) > } 

{ I 1 < HCS params : < HCS struct > > } 

{ I 1 < TIME_GROUP : bit (2) > } 

{ I 1 < GUAR_CONSTANT_PWR_BLKS : bit (2) >} ; 

< CCN Support Description struct > ::= 

< NumberCells : bit (7) > 

{ CCN_SUPPORTED : bit } * (val(Number_Cells)) ; 

< lu Mode Neighbour Cell Params struct > ::= 

< NR_OF_REMAINING_CELLS : bit (4) > 

{ I 1 < lu Mode Cell Selection Params : <lu Mode Cell Selection struct» } * (val(NR_OF_REMAINING_CELLS)); 

< lu Mode Cell Selection struct > ::= 

< CELL BAR QUALIFY 3 : bit (2) > 

{ I 1 < SI13Alt PBCCH Location: < SI13 PBCCH Location struct > > }; 

< lu mode Only Neighbour Cell params struct > ::= 

< START_FREQUENCY : bit (10) > 

< lu mode Only Cell selection params : < lu mode Only Cell Selection struct > > 

< NR_OF_REMAINING_CELLS : bit (4) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit (1 + val{FREO_DIFF_LENGTH)) > 

< lu mode Only Cell selection params : < lu mode Only Cell Selection struct > >} * 
(val(NR_OF_REMAINING_CELLS)); 
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< lu Mode Only Cell Selection struct > ::= 


< BSIC : bit (6) > 


< CELL BAR QUALIFY 3 : bit (2) > 


<SAME RA AS SERVING CELL : bit (1)> 


{0|1 


< GPRS RXLEV ACCESS MIN : bit (6) > 




< GPRS MS TXPWR MAX CCH : bit (5) > } 


{0|1 


< GPRS TEMPORARY OFFSET : bit (3) > 




< GPRS PENALTY TIME : bit (5) } 


{0|1 


< GPRS RESELECT OFFSET : bit (5) > } 


{0|1 


< HCS params : < HCS struct > > } 


{0|1 


< SI13Alt PBCCH Location : < SI13 PBCCH Location struct > >}; 



Table 11.2.20.2: PSI3 Information element details 



PAGE_MODE (2 bit field) 

This field describes which type of page mode used, i.e. either normal paging, extended paging, paging reorganization or 
same as before from the previous page mode. The mobile station shall ignore this field if the message is received on the 
PACCH. Coding of this field is defined in 3GPP TS 44.018 

PSI3_CHANGE_MARK (2 bit field) 

The PSI3 change mark field is changed each time information has been updated in any of the PSI3, PSD bis, PSI3 ter or 

PSI3 quater messages. A new value indicates that the mobile station shall re-read the information from the PSI3 and all 

PSI3 bis, PSI3 ter and PSI3 quater messages. The coding of this field is network dependent. 

Range: 0-3. 

PSI3_BIS_COUNT (4 bit field) 

This field is coded as the binary representation of the PSD bis index (in the PSD bis message) for the last (highest 

indexed) individual PSD bis message. 

Range: 0-15. 

Serving Cell Parameters: 

CELL_BAR_ACCESS_2 (1 bit field) 

This field combines the CELL_BAR_ACCESS and CELL_BAR_QUALIFY parameters and indicates the status for cell 

reselection, see 3GPP TS 45.008: 

Status for cell reselection is set to normal; 

1 Status for cell reselection is set to barred. 

EXC_ACC(1 bit field) 

EXC_ACC is used by the network to prevent mobiles without exclusive access rights from camping on the cell. The 

usage of EXC_ ACC is described in 3GPP TS 43.022. The coding of EXC_ ACC is as follows: 

The cell is not used for SoLSA exclusive access. 

1 The cell is used for SoLSA exclusive access. 

GPRS_RXLEV_ACCESS_MIN (6 bit field) 

The GPRS_RXLEV_ACCESS_MIN field is coded as the binary representation of the 'RXLEV_ACCESS_MIN' 

defined in 3GPP TS 45.008. It is the minimum received level at the mobile station required for access to the system. 

GPRS_MS_TXPWR_MAX_CCH (5 bit field) 

The GPRS_MS_TXPWR_MAX_CCH field is coded as the binary representation of the 'power control level' in 
3GPP TS 45.005 corresponding to the maximum TX power level a mobile station may use when accessing on a packet 
control channel. This value shall be used by the mobile station according to 3GPP TS 45.008. 

HCS struct 

If the HCS struct is omitted for the serving cell, HCS is not used and the HCS parameters for the other cells shall be 
neglected i.e the HCS signal strength threshold shall be set to infinity for all cells. Otherwise PRIORITY_CLASS and 
HCS_THR are defined. The use of the HCS parameters is defined in 3GPP TS 45.008. 
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PRIORITY_CLASS (3 bit field) 

The PRIORITY_CLASS field contains the binary representation of the HCS priority for the cell. 

Bit 

321 

Lowest Priority 



111 Highest Priority 

HCS_THR (5 bit field) 

The HCS_THR is the HCS signal strength threshold 

Bit 

5432 1 

000 -llOdBm 

000 1 -108 dBm 

11111 -48 dBm 

MULTIBAND_REPORTING (2 bit field) 

Binary encoding of multiband reporting parameter as specified in 3GPP TS 45.008 

Range 0-3. 

General Cell Selection Parameters 

GPRS_CELL_RESELECT_HYSTERESIS (3 bit field) 

The GPRS_CELL_RESELECT_HYSTERESIS field indicates the Additional Hysteresis which apphes in Ready state 
in A/Gb mode and RRC-Cell_Shared state in lu mode for cells in same RA. This field is encoded according to the 
following table: 



Bit 




321 




000 


OdB 


001 


2dB 


010 


4dB 


01 1 


6dB 


100 


8dB 


1 01 


10 dB 


1 10 


12 dB 


1 1 1 


14 dB 



C31_HYST(1 bit field) 

The C31_HYST field indicates if set to 1 that the GPRS_CELL_RESELECT_HYSTERESIS shall be applied to the 

C31 criterion. 

C32_QUAL(1 bit field) 

C32_QUAL is a flag indicating an exception rule for GPRS_RESELECT_OFFSET according to 3GPP TS 45.008. 

T_RESEL (3 bit field) 

If the mobile station has performed an abnormal release with cell reselection (see sub-clause 9.4.2) from this cell, the 
mobile station is not allowed to reselect this cell for T_RESEL seconds if another cell is available. The default value of 
T_RESEL is 5 s. If the field is omitted from the message, the default value shall be used by the mobile station. 

Bit 

321 

000 5s 

00 1 10 s 

10 15 s 

Oil 20 s 

10 30 s 

10 1 60 s 

110 120 s 

111 300 s 
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RA_RESELECT_HYSTERESIS (3 bit field) 

The RA_RESELECT_HYSTERESIS field indicates in both STANDBY and READY state in A/Gb mode and RRC-Idle 
and RRC-Connected mode in lu mode the additional hysteresis which applies when selecting a cell in a new Routing 
Area. If this field is not present, the default value is GPRS_CELL_RESELECT_HYSTERESIS. This field is encoded 
according to the following table: 



Bit 




321 




000 


OdB 


001 


2dB 


010 


4dB 


01 1 


6dB 


100 


8dB 


101 


10 dB 


1 10 


12 dB 


1 1 1 


14 dB 



Neighbour Cell Parameters 

The Neighbour cell parameters areused to specify neighbour cells (BA(GPRS)) and their corresponding cell selection 
parameters. The Neighbour cell parameters are specified in PSI3 and in at least one instance of PSBbis. If one instance 
of PSBbis is not sufficient to specify the cell selection parameters of all neighbour cells, the remaining neighbour cells 
are specified in consecutive instances of PSBbis. If all information fits within the PSB message, one instance of 
PSBbis without any neighbour cell parameters is broadcast. 

NOTE: For efficient coding, cells with common cell selection parameters may be grouped together. 

Building of BA(GPRS) is defined in sub-clause 5.6.3.2. 

START_FREQUENCY (10 bit field) 

The START_FREQUENCY defines the ARFCN for the first carrier in the list (ARFCN(O)). FREQ_DIFF_LENGTH 

(3 bit field) 

This field is required to calculate the number of bits to be used for the FREQUENCY_DIFF field in the current 

frequency group. 

FREQUENCY_DIFF (l+val(FREQ_DIFF_LENGTH) bit field) 

Each FREQUENCY_DIFF parameter field specifies the difference in frequency to the next carrier to be defined. The 

FREQUENCY_DIFF parameter encodes a non negative integer in binary format (W). 

Each frequency following the start frequency (ARFCN(O)) and belonging to the Frequency List struct is then calculated 
by the formula ARFCN(n) = (ARFCN(n-l) + W(n) ) modulus 1024, n=l, . . ., val(NR_OF_REMAINING_CELLS. 

General rules for handling neighbour cell parameter default values 

The first neighbour cell defined in PSB uses as its default parameter values the parameter values defined for the serving 
cell. If a parameter is omitted for the serving cell then the specified default value shall be used. The following 
neighbour cells use the parameter values of the previous neighbour cell as their default values. 

Cell Selection params 

The first field of the Cell Selection struct, BSIC, defines the BSIC of the cell and then comes the fields 
CELL_BAR_ACCESS_2, ECX_ACC and SAME_RA_AS_SERVING_CELL. Then follows none, some, or all of the 
fields GPRS_RXLEV_ACCESS_MIN, GPRS_MS_TXPWR_MAX_CCH, GPRS_TEMPORARY_OFFSET, 
GPRS_PENALTY_TIME, GPRS_RESELECT_OFFSET , HCS params, SI13_PBCCH_LOCATION, PCCH_TYPE 
and PSIl_REPEAT_PERIOD. If fields are omitted, the values for these parameters are the same as for the preceding 
cell unless otherwise specified for the parameter. 

BSIC (6 bit field) 

The BSIC field is coded as the 'Base Station Identity Code' defined in 3GPP TS 23.003. One BSIC for each carrier in 

BA(GPRS) is defined. 

CELL_BAR_ACCESS_2 (1 bit field) 

EXC_ACC(1 bit field) 

For definition see Serving Cell parameters 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 281 ETSI TS 144 060 V6.28.0 (2010-03) 

SAME_RA_AS_SERVING_CELL (1 bit field) 

The same RA as serving cell field contains one bit, set to 

if the cell is in a Routeing Area different from the serving cell, or 

1 if the cell is in the same Routeing Area as the serving cell. 

GPRS_TEMPORARY_OFFSET (3 bit field) 

The GPRS_TEMPORARY_OFFSET field indicates the negative offset to C32 that the mobile station shall use for 
duration of GPRS_PENALTY_TIME. It is used by the mobile station as part of its calculation of C32 for the cell 
reselection process. Default value is dB. If the field is omitted for the first neighbour cell, the default value shall be 
used by the mobile station. 



Bit 




321 




000 


OdB 


001 


10 dB 


010 


20 dB 


1 1 


30 dB 


1 00 


40 dB 


101 


50 dB 


1 10 


60 dB 


1 1 1 


infinity 



GPRS_PENALTY_TIME (5 bit field) 

The GPRS_PENALTY_TIME defines the length of time for which GPRS_TEMPORARY_OFFSET is active. 

Bit 

5432 1 

000 10 s 

1 20 s 

11111 320 s 

GPRS_RESELECT_OFFSET (5 bit field) 

GPRS_RESELECT_OFFSET is used by the mobile station to apply a positive or negative offset and a hysteresis to the 
GPRS cell reselection criterion. Default value is dB. If the field is omitted from the message, the default value shall be 
used by the mobile station. 

Bit 

5432 1 

-52 dB 

1 -48 dB 

1010 -12 dB 
1011 -10 dB 

10110 H-12dB 

10111 H-16dB 

11111 H-48 dB 
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SI13_PBCCH_LOCATION construction 

The optional SI13_PBCCH_LOCATION struct may either indicate the position of the SI 13 message or a PBCCH 
position. If not included, SI3 and SI4 in the neighbour cell indicates if the neighbour cell supports GPRS. 

SI13_LOCATION (1 bit field) 

The SI13_LOCATION field, if present, indicates the logical channel where the SYSTEM INFORMATION TYPE 13 is 

broadcast (see 3GPP TS 45.002). 

SYSTEM INFORMATION TYPE 1 3 message is sent on BCCH norm 

1 SYSTEM INFORMATION TYPE 13 message is sent on BCCH ext 

PBCCH_LOCATION (2 bit field) 

The PBCCH_LOCATION field, if present, indicates the location of the PBCCH on the BCCH carrier (see 

3GPP TS 45.002). If the PBCCH location for a neighbour cell is given using this field, the TSC shall equal the BCC 

determined by the BSIC of that cell. 

bit 

2 1 

PBCCH on TN 1 of BCCH carrier 

1 PBCCH on TN 2 of BCCH carrier 

1 PBCCH on TN 3 of BCCH carrier 
1 1 PBCCH on TN 4 of BCCH carrier 

PSIl_REPEAT_PERIOD (4 bit field) 

The PSIl_REPEAT_PERIOD field indicates the PSI repeat period. The field is coded according to the following table: 

bit 

4321 

PSIl repeat period = 1 

1 PSIl repeat period = 2 

1111 PSIl repeat period = 16 

LSA Parameters IE 

The LSA Parameters IE contains a list of LSA_ID(s) corresponding to the entries in the Neighbour Cell Parameters. 
Some entries in LSA parameters may be empty. The entries in the LSA Parameters IE are listed in the same order as in 
the Neighbour Cell Parameters and the number of entries (nr_of_frequencies_or_cells) should be the same. In case there 
are too few entries in the LSA Parameters IE, empty entries shall be added at the end. In case there are too many entries 
in the LSA parameters, the last shall be discarded. The 'LSA parameters IE' is defined in sub-clause 12.28. 

LSAJD (24 bit field) 

The purpose of the LSAJD field is to identify a LSA. The LSA ID value field is coded as specified in 

3GPPTS 23.003. 

Short LSAJD (10 bit field) 

The purpose of the Short LSAJD field is to identify a LSA. The LSA ID defined by the Short LSAJD is a LSAJD as 
specified in 3GPP TS 23.003 with bit set to "0" bit 1 to 10 set to the value of the Short LSAJD field (LSB in bit 1, 
MSB in bit 10) and bit 1 1 to 23 set to "0". 

TIME_GROUP (2 bit field) 

The TIME_GROUP defines which time group (see 3GPP TS 45.002) the cell belongs to 



bit 




21 




00 


Time Group 


01 


Time Group 1 


10 


Time Group 2 


1 1 


Time Group 3 
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GUAR_CONSTANT_PWR_BLKS (2 bit field) 

This field indicates the guaranteed number of constant power blocks in the neighbour cell. These are the blocks that the 
MS can use to perform neighbour cell measurements (see 3GPP TS 45.008). Note that there may be more CPBCCH 
blocks or allowed paging blocks in the neighbour cell than what is indicated in this field, but never less. 

bit 

2 1 Blocks at constant power 

00 4 

01 5 
10 6 

1 1 12 (i.e. BS_PAG_BLKS_RES = in that cell) 

Cell Identification 

This information element is defined in sub-clause 12.23. 

CCN Support Description 

CCN_SUPPORTED (1 bit field) 

This parameter is used for determining whether the mobile station shall enter CCN mode when re-selecting a cell and 

CCN is enabled. The use of these bits is described in sub-clause°8.8.2a ("CCN support description"): 

Bit 

CCN is enabled towards the corresponding cell 

1 CCN is disabled towards the corresponding cell 

CELL BAR QUALIFY 3 (2 bit field) 

This information element is defined in 3GPP TS 44.018. 

lu mode Neighbour Cell Parameters 

The lu mode Neighbour Cell Parameters are used to specify lu mode (and A/Gb mode) capable neighbouring cells 
(BA(GPRS)) and their corresponding cell selection parameters. The lu mode Neighbour Cell Parameters are specified 
in PSI3 and in at least one instance of PSBbis. If one instance of PSBbis is not sufficient to specify the cell selection 
parameters of all lu mode capable neighbouring cells, the remaining lu mode capable neighbouring cells are specified in 
consecutive instances of PSBbis. If all information fits within the PSI3 message, one instance of PSBbis without any lu 
mode Neighbour Cell Parameters is broadcast. 

NOTE: For efficient coding, cells with common cell selection parameters may be grouped together. 

Building of BA(GPRS) is defined in sub-clause 5.6.3.2. 

lu mode Only Neighbour Cell Parameters 

The lu mode Only Neighbour Cell Parameters are used to specify lu mode only capable neighbouring cells and their 
corresponding cell selection parameters. The lu mode Only Neighbour Cell Parameters are specified in PSI3 and in at 
least one instance of PSBbis. If one instance of PSBbis is not sufficient to specify the cell selection parameters of all lu 
mode only capable neighbouring cells, the remaining lu mode only capable neighbouring cells are specified in 
consecutive instances of PSBbis. If all information fits within the PSI3 message, one instance of PSBbis without any lu 
mode Only Neighbour Cell Parameters is broadcast. 

lu mode Neighbour Cell params struct 

This struct presents supplementary information fox lu mode capable cells. The struct may be included in this message 
and assigns lu mode parameter values to the neighbouring cells defined by the message. lu mode capable neighbouring 
cells are defined by the Neighbour Cell Parameter IE. The lu mode Neighbour Cell params struct values are assigned 
to the neighbouring cells in the same order they appear in the PSB and PSBbis messages. 



1 1 .2.21 Packet System Information Type 3 bis 

This message is sent by the network on the PBCCH and PACCH giving information of the BCCH allocation in the 
neighbour cells and cell selection parameters for non-serving cells. This message shall not be segmented across more 
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than one RLC/MAC control block by using the procedures specified in sub-clause 9. 1 . 12a. If not all information fits 
into one instance of the PSDbis message, the PSBbis message can be repeated. Special requirements for the 
transmission of this message apply on PBCCH, see 3GPP TS 45.002. 

Message type: PACKET SYSTEM INFORMATION TYPE 3 BIS 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.21.1: PSI3 bis information elements 

< PSI3 bis message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI3_CHANGE_MARK : bit (2) > 

< PSI3_BISJNDEX : bit (4) > 

< PSI3_BIS_C0UNT : bit (4) > 

{ < Neighbour cell parameters : { 1 < Neiglibour cell params struct > } ** > 

< Neighbour Cell parameters 2 : { 1 < Neighbour Cell params 2 struct > } ** > 

{ null I bit** = < no string > 

I 1 -- Release 1998 additions: 

{ I 1 < LSA Parameters : < LSA Parameters IE » } 

{ null I bit** = < no string > 

I 1 -- Release 1999 additions: 

< COMPACT Neighbour Cell Parameters : { 1 < COMPACT Neighbour Cell params 2 struct > } ** > 
-- The value '1 ' was used in an earlier version of the protocol and shall not be used. 

{ null I bit** = < no string > 

I 1 -- R4 additions: 

{ I 1 < CCN Support Description : < CCN Support Description struct » } 
{ null I bit** = < no string > 
I 1 -- REL-5 additions: 

< lu Mode Neighbour Cell Parameters : { 1 < lu Mode Neighbour Cell params struct > } ** > 

--Supplementary information for dual lu mode and A/Gb mode capable 
cells 

< lu mode Only Neighbour Cell Parameters : { 1 < lu mode Only Neighbour Cell params struct > } ** > 

< padding bits >}}}}}// - truncation at end of message allowed, bits '0' assumed 
! < Distribution part error : bit (*) = < no string > > ; 

< Neighbour cell params struct > ::= 

< START_FREQUENCY : bit (10) > 

< Cell selection params : < Cell Selection struct > > 

< NR_OF_REMAINING_CELLS : bit (4) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit (1 + val{FREQ_DIFF_LENGTH)) > 

< Cell selection params : <Cell Selection struct> > } * (val(NR_OF_REMAINING_CELLS)) ; 

< Cell Selection struct > ::= 

< BSIC : bit (6) > 

< CELL_BAR_ACCESS_2 : bit > 

< EXC_ACC : bit > 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

{ I 1 < GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_MAX_CCH : bit (5) > } 
{ I 1 < GPRS_TEMPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TIME : bit (5) > } 

{ I 1 < GPRS_RESELECT_OFFSET : bit (5) > } 

{ I 1 < HCS params : < HCS struct > > } 

{ I 1 < SI13_PBCCH_L0CATI0N : < SI13_PBCCH_L0CATI0N struct > > } ; 

< SI13_PBCCH_L0CATI0N struct > ::= 

{ < SI13_L0CATI0N : bit (1) > 
I 1 < PBCCH_LOCATION : bit (2) > 

< PSI1_REPEAT_PERI0D : bit (4) > } ; 

< HCS struct > ::= 

< PRIORITY_CLASS : bit (3) > 

< HCS_THR : bit (5) > ; 
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< Neighbour Cell params 2 struct > ;:= 

{ 00 -- Message escape 

{ 1 < NCP2 Repeat struct > 

< CELL_PARAMS_POINTER : bit (2) > } " -Up to four pointers to the 'Neigbour parameter set 

< Neighbour parameter set : < Neighbour parameter set struct > > * (1 + max(val{CELL_PARAIVIS_POINTER))) 

! < Message escape: { 01 | 1 | 1 1 } bit** = < no string » } ; -- Reserved for future use 

< NCP2 Repeat struct > ::= 

{ 1 < START_FREQUENCY : bit (1 0) > -- r\/lultiple START FREQ/FREQ DIFF sets may be defined 

< NCP2 Property struct > 

{ < NR_OF_REIVIAINING_CELLS : { bit (4) - 0000 } > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit (1 + val{FREQ_DIFF_LENGTH)) > 

< NCP2 Property struct > } * (val(NR_OF_REMAINING_CELLS)) 

< NCP2 Repeat struct > -- Repeated recursiveiy 

I 0000 } -- Breal< recursion (NR_OF_REI\/IAINING_CELLS == 0) 

I } ; -- End recursion (no more START_FREQUENCY) 

< NCP2 Property struct > ::= 

< SAIVIE_RA_AS_SERVING_CELL : bit (1) > 

< CELL_BAR_ACCESS_2 : bit > 

< BCC : bit (3) > ; 

< Neighbour parameter set struct > ::=. 

{ I 1 < NCC : bit (3) > } 

< EXC_ACC : bit > 

{ I 1 < GPRS_RXLEV_ACCESS_IVIIN : bit (6) > } 

{ I 1 < GPRS_IVIS_TXPWR_IVIAX_CCH : bit (5) > } 

{ I 1 < PRIORITY_CLASS : bit (3) > } 

{ I 1 < HCS_THR : bit (5) >} 

{ I 1 < SI13_PBCCH_L0CATI0N : < SI13_PBCCH_L0CATI0N struct > > } 

< GPRS_TEI\/IPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TII\/IE : bit (5) > 

< GPRS_RESELECT_OFFSET : bit (5) > ; 

< COMPACT Neighbour Cell params 2 struct > ::= 

{ 00 -- Message escape 

{ 1 < COMPACT NCP2 Repeat struct > 

< CELL_PARAI\/IS_POINTER : bit (2) > } ** -Up to four pointers to the 'C Neighbour parameter set' 
<COIVIPACT Neighbour parameter set : 

<COMPACT Neighbour parameter set struct > > * (1+ max(val{CELL_PARAMS_POINTER))) 

! < Message escape: { 01 | 1 | 11 } bit** = < no string » } ; -- Reserved for future use 

< COMPACT NCP2 Repeat struct > ::= 

{ 1 < START_FREQUENCY : bit (1 0) > -- Multiple START FREQ/FREQ DIFF sets may be defined 

< COMPACT NCP2 Property struct > 

{ < NR_OF_REIVIAINING_CELLS : { bit (4) - 0000 } > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit (1 + val{FREQ_DIFF_LENGTH)) > 

< COMPACT NCP2 Property struct > } * (val(NR_OF_REMAINING_CELLS)) 

< COMPACT NCP2 Repeat struct > -- Repeated recursively 

I 0000 } -- Break recursion (NR_OF_REMAINING_CELLS == 0) 

I } ; -- End recursion (no more START_FREQUENCY) 
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< COMPACT NCP2 Property struct > ::= 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

< CELL_BAR_ACCESS_2 : bit > 

< BCC : bit (3) > 

{ I 1 < TIME_GROUP : bit (2) > }; 

< COIVIPACT Neighbour parameter set struct > ::= 

{ I 1 < NCC : bit (3) > } 

< EXC_ACC : bit > 

{ I 1 < GPRS_RXLEV_ACCESS_I\/IIN : bit (6) > } 
{ I 1 < GPRS_IVIS_TXPWR_IVIAX_CCH : bit (5) > } 
{ I 1 < GPRS_PRIORITY_CLASS : bit (3) > } 
{ I 1 < GPRS_HCS_THR : bit (5) >} 

< GPRS_TEI\/IPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TII\/IE : bit (5) > 

< GPRS_RESELECT_OFFSET : bit (5) > 

{ I 1 < GUAR_CONSTANT_PWR_BLKS : bit (2) >} ; 

< CCN Support Description struct > ::= 

< Number_Cells : bit (7) > 

{ CCN_SUPPORTED : bit } * (val(Number_Cells)) ; 

< lu mode neighbour cell params struct > ::= 

< NR_OF_REIVIAINING_CELLS : bit (4) > 

{ I 1 < lu Mode Cell Selection Params : <lu l\/lode Cell Selection struct» } * {val(NR_OF_REMAINING_CELLS)); 

< lu Mode Cell Selection struct > ::= 

< CELL BAR QUALIFY 3 : bit (2) > 

{ I 1 < SI13Alt PBCCH Location: < SI13 PBCCH Location struct > > }; 

< lu mode Only Neighbour Cell params struct > ::= 

< START_FREQUENCY : bit (10) > 

< lu mode Only Cell selection params : < lu mode Only Cell Selection struct > > 

< NR_OF_REMAINING_CELLS : bit (4) > 

< FREQ_DIFF_LENGTH : bit (3) > 

{ < FREQUENCY_DIFF : bit (1 + val{FREO_DIFF_LENGTH)) > 

< lu mode Only Cell Selection params : < lu mode Only Cell Selection struct > >} * 

(val(NR_OF_REMAINING_CELLS)); 

< lu Mode Only Cell Selection struct > :;= 

< BSIC : bit (6) > 

< CELL BAR QUALIFY 3 : bit (2) > 

< SAME_RA_AS_SERVING_CELL : bit (1) > 

{ I 1 < GPRS_RXLEV_ACCESS_MIN : bit (6) > 

< GPRS_MS_TXPWR_MAX_CCH : bit (5) > } 
{ I 1 < GPRS_TEMPORARY_OFFSET : bit (3) > 

< GPRS_PENALTY_TIME : bit (5) } 

{ I 1 < GPRS_RESELECT_OFFSET : bit (5) > } 

{ I 1 < HCS params : < HCS struct > > } 

{ I 1 < SI13Alt PBCCH Location : < SI13 PBCCH Location struct > >}; 

Table 11.2.21.2: PSI3 bis information element details 

PAGE_MODE (2 bit field) 
See description under PSI3. 

PSI3_CHANGE_MARK (2 bit field) 
See description under PSI3. 

PSI3_BIS_INDEX (4 bit field) 

The PSI3_BIS_INDEX field is used to distinguish individual PSI3 bis messages containing information about different 
neighbour cells. The field can take the binary representation of the values to n, where n is the index of the last PSI3 
bis message. (PSI3 bis count). 

PSI3_BIS_COUNT (4 bit field) 
See description under PSI3. 
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General rules for handling neighbour cell parameter default values 

The first neighbour cell defined in the first PSBbis instance uses as its default parameter values the parameter values 

defined for the last neighbour cell in PSI3. 

The following neighbour cells in PSBbis use the parameter values of the previous neighbour cell as their default values. 

This principle of referring to the previous cell applies independently of the coding used in PSBbis (Neighbour cell 
parameters, Neighbour cell parameters 2 and COMPACT Neighbour Cell Parameters). 

This principle also applies when going from PSBbis instance i over to PSBbis instance i+1. 

Neighbour cell params struct 

The coding of the Neighbour cell parameters is described under PSB. 

Neighbour cell params 2 struct 

This coding may be used if the number of neighbour cells is high and many cells share common parameter values. The 
structure contains pointers to the list of sets of actual parameters. The coding of actual parameters that are contained in 
or referenced by the Neighbour Cell params 2 struct is described in PSB. 

COMPACT Neighbour Cell params struct 

The coding of the Neighbour cell parameters is the same as the coding of the Neighbour cell params struct 2, except the 
two additional parameters, TIME_GROUP and GUAR_CONSTANT_PWR_BLKS. The coding of actual parameters 
that are contained in or referenced by the COMPACT Neighbour Cell params struct is described in PSB. 

The following parameters (CELL_PARAMS_POINTER, BCC and NCC) are not defined in PSB: 

CELL_PARAMS_POINTER (2 bit field) 

Pointer to the parameter set valid for a certain cell group (up to four). 

BCC (3 bit field) 
BTS Colour Code. 

Neighbour parameter set struct and COMPACT Neighbour parameter set struct 

The actual parameter values for the Neighbour Cell params 2 struct and the COMPACT Neighbour Cell params struct 
are given is these structures. Default values for absent parameters are defined according to the general rule given above, 
except: 

NCC : bit (3). Network Colour Code. The default value is given by the serving cell. 

LSA Parameters IE 

The LSA Parameters IE is described under PSB and in sub-clause 12.28. 

CCN Support Description 

CCN_SUPPORTED (1 bit field) 

This parameter is used for determining whether the mobile station shall enter CCN mode when re-selecting a cell and 

CCN is enabled. The use of these bits is described in sub-clause°8.8.2a: 

Bit 

CCN is enabled towards the corresponding cell 

1 CCN is disabled towards the corresponding cell 

CELL BAR QUALIFY 3 (2 bit field) 

This information element is defined in 3GPP TS 44.018. 

lu mode Neighbour Cell params struct 

This struct presents supplementary information for/w mode capable cells. The struct may be included in this message 
and assigns lu mode parameter values to the neighbouring cells defined by the message. lu mode capable neighbouring 
cells may be defined by the Neighbour Cell parameters and the Neighbour Cell parameters 2 lEs. The lu mode 
Neighbour Cell params struct values are assigned to the neighbouring cells in the same order they appear in the PSB 
and PSBbis messages. 
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1 1 .2.21 a Packet System Information Type 3 ter 

This message is sent by the network on the PBCCH or PACCH giving information on additional measurement and 
reporting parameters. This message shall not be segmented across more than one RLC/MAC control block by using the 
procedures specified in sub-clause 9.1.12a. If not all information fits into one instance of the PSBter message, the 
PSBter message can be repeated. Special requirements for the transmission of this message apply on PBCCH, see 
3GPP TS 45.002. 

Message type: PACKET SYSTEM INFORMATION TYPE 3 TER 

Direction: network to mobile station 

Classification: distribution message 

Table 11.2.21a.1: PSI3 ter information elements 

< PSI3 ter message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI3_CHANGE_MARK : bit (2) > 

< PSI3_TER_INDEX : bit (4) > 

< PSI3_TER_C0UNT : bit (4) > 

{ { I 1 < Real Time Difference Description : < Real Time Difference Description struct » } 
{ I 1 < GPRS REP_PRIORITY Description : < GPRS REP PRIORITY Description struct » } 
< padding bits >} II - truncation at end of message allowed, bits '0' assumed 

I < Distribution part error : bit (*) = < no string > > ; 



< Real Time Difference Description struct > ::= 

{ I 1 {011 < CelLlndex_Start_RTD : bit (7) > } 

< RTD Struct : < RTD6 Struct » 

{ < RTD Struct : < RTD6 Struct » } **1 } 
{ I 1 { I 1 < CelLlndex_Start_RTD : bit (7) > } 

< RTD Struct : < RTD 12 Struct » 

{ < RTD Struct : < RTD1 2 Struct » } "1 }; 



default value=0 

■ '0' : increment by 1 the index of the GSM Neighbour Cell list 

■ default value=0 

- '0' : increment by 1 the index of the GSM Neighbour Cell list 



< RTD6 Struct > ::= 

{ I 1 < RTD : bit (6) > } ; 

< RTD 12 Struct >::= 

{0| 1 <RTD:bit(12)>} ; 



-'0' means no RTD for this cell 



'0' means no RTD for this cell 



< GPRS REP PRIORITY Description struct > ::= 
< Number_Cells : bit{7) > 
{ < REP_PRIORITY : bit > } * (val(Number_Cells)) ; 



Table 11.2.21a.2: PSI3 ter information element details 



PAGE_MODE (2 bit field) 
See description under PSI3. 

PSI3_CHANGE_MARK (2 bit field) 
See description under PSI3. 

PSI3_TER_INDEX (4 bit field) 

The PSI3_TER_INDEX field is used to distinguish individual PSI3 bis messages containing information about different 
neighbour cells. The field can take the binary representation of the values to n, where n is the index of the last PSI3 ter 
message. (PSI3 ter count). 

PSI3_TER_COUNT (4 bit field) 

This field is coded as the binary representation of the PSI3 ter index (in the PSI3 ter message) for the last (highest 

indexed) individual PSI3 ter message. 

Range: 0-15. 
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Real Time Difference Description 

Cell_Index_Start_RTD (7 bit field) 

This field indicates the GSM Neighbour Cell list index for the first RTD parameter. When missing, the value '0' is 

assumed. 

RTD (6 or 12 bit field) is defined in 3GPP TS 45.008. 
The use of these parameters is defined in sub-clause 5.6.3.4. 

GPRS REP PRIORITY Description 

REP_PRIORITY bit: 

Normal reporting priority 

1 High reporting priority 

The use of these bits is defined in sub-clause 5.6.3.5. 



1 1 .2.21 a.1 GPRS REP PRIORITY description 

A GPRS REP PRIORITY description construction shall be included in one and only one instance of the PACKET 
SYSTEM INFORMATION TYPE 3 TER message within the consistent set of PACKET SYSTEM INFORMATION 
TYPE 3 TER messages. 

1 1 .2.21 b Packet System Information Type 3 quater 

This message is sent by the network on the PBCCH or PACCH giving information on 3G Neighbour Cells and 
additional measurement and reporting parameters. This message shall not be segmented across more than one 
RLC/MAC control block by using the procedures specified in sub-clause 9.1.12a. If not all information fits into one 
instance of the PSBquater message, the PSBquater message can be repeated. Special requirements for the transmission 
of this message apply on PBCCH, see 3GPP TS 45.002. 

Message type: PACKET SYSTEM INFORMATION TYPE 3 QUATER 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.21b.1: PSI3 quater information elements 

< PSI3 quater message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI3_CHANGE_MARK : bit (2) > 

< PSI3_QUATERJNDEX : bit (4) > 

< PSI3_QUATER_C0UNT : bit (4) > 

{ { |1 < GPRS REP_PRIORITY Description : < GPRS REP PRIORITY Description struct » } 
{ I 1 < 3G Neighbour Cells Description : < 3G Neighbour Cells Description struct » } 
{ I 1 < 3G MEASUREMENT Parameters Description : 

< 30 I\/1EASUREMENT PARAIVIETERS Description struct » } 
{ I 1 < 3G Initial Dedicated Mode Reporting Description : 

< 30 Initial Dedicated Mode Reporting Description struct » } 

{ null I bit** < no string> - Receiver compatible witli earlier release 

I 1 ~ Additions in release R5: 

{ I 1 < GPRS 3G Additional Measurement Parameters Description : 

< OPRS 30 Additional Measurement Parameters Description struct » } 
{ I 1 < GPRS 3G Additional Measurement Parameters Description 2: 

< OPRS 30 Additional Measurement Parameters Description 2 struct » } 
{ null I bit** = < no string > --Receiver compatible with earlier release 

I 1 -Additions in Release 6: 

< 3G_CCN_ACTIVE : bit > 

< padding bits >}}}// -- truncation at end of message allowed, bits '0' assumed 
! < Distribution part error : bit (*) = < no string > > ; 

< OPRS REP PRIORITY Description struct > ::= 

< NumberCells : bit{7) > 

{ < REP_PRIORITY : bit > } * (val(Number_Cells)) ; 

< 30 Neighbour Cell Description struct > ::= 

{ I 1 < lndex_Start_3G : bit (7) > } 

{ I 1 < AbsoluteJndex_Start_EMR : bit (7) > } 

{ I 1 < UTRAN FDD Description : < UTRAN FDD Description struct » } 

{ I 1 < UTRAN TDD Description : < UTRAN TDD Description struct » } ; 

< UTRAN FDD Description struct > ::= 

{ I 1 < Bandwidth_FDD : bit (3) > } 

{ 1 < Repeated UTRAN FDD Neighbour Cells : < Repeated UTRAN FDD Neighbour Cells struct » } ** ; 

< Repeated UTRAN FDD Neighbour Cells struct > ::= 

< FDD-ARFCN : bit (1 4) > -- The value '1 ' was used in an earlier 

- version of the protocol and shall not be used. 

< FDDJndicO : bit > 

< NR_OF_FDD_CELLS : bit (5) > 

< FDD _CELLJNFORMATION Field : bit(p(NR_OF_FDD_CELLS)) > ; 

-- p(x) defined in table 1 1 .2.9b.2.a/30PP TS 44.060. 

< UTRAN TDD Description struct > ::= 

{ I 1 < Bandwidth_TDD : bit (3) > } 

{ 1 < Repeated UTRAN TDD Neighbour Cells : < Repeated UTRAN TDD Neighbour Cells struct » } ** ; 

< Repeated UTRAN TDD Neighbour Cells struct > ::= 

< TDD-ARFCN : bit (1 4) > -- The value '1 ' was used in an earlier 

- version of the protocol and shall not be used. 

< TDDJndicO : bit > 

< NR_OF_TDD_CELLS : bit (5) > 

< TDD_CELLJNFORMATION Field : bit{q{NR_OF_TDD_CELLS)) > ; 

-- q(x) defined in table 1 1 .2.9b.2.b/30PP TS 44.060. 

< 30 MEASUREMENT PARAMETERS Description struct > ::= 

< Qsearch_P : bit (4) > 

< 3G_SEARCH_PRI0 : bit > 

{ I 1 < FDD_GPRS_Qoffset : bit (4) > -- FDD information 

< FDD_Qmin : bit (3) > } 
{ I 1 < TDD_GPRS_Qoffset : bit (4) > } ; -- TDD information 
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< 3G Initial Dedicated Mode Reporting Description struct > ::= 






< 3G_BAJND : bit > 






< QsearchJ : bit (4) > 






< Qsearch_C_lnitial : bit (1) > 






{ 1 1 < FDD Qoffset : bit (4) > 


FDD information 


<FDD REP QUANT: bit (1)> 






< FDD_MULTIRAT_REPORTING : bit (2) > } 






{ 1 1 < TDD Qoffset : bit (4) > 


TDD 


information 


< TDD_MULTIRAT_REPORTING : bit (2) > } ; 






< GPRS 3G Additional Measurement Parameters Description struct > 


::. 




< FDD Qmin Offset : bit (3) > 




-- FDD information 


< FDD_RSCPmin : bit (4) > ; 






< GPRS 3G Additional Measurement Parameters Description 2 struct 


> ::= 




{ 1 1 < FDD_REP0RTING_THRESHQLD_2 : bit (6) > } ; 




-- FDD information 



Table 11.2.21b.2: PSI3 quater information element details 



PAGE_MODE (2 bit field) 
See description under PSI3. 

PSI3_CHANGE_MARK (2 bit field) 
See description under PSI3. 

PSI3_QUATER_INDEX (4 bit field) 

The PSI3_QUATER_INDEX field is used to distinguish individual PSI3 quater messages containing information about 
different neighbour cells. The field can take the binary representation of the values to n, where n is the index of the 
last PSI3 quater message. (PSI3 quater count). 

PSI3_QUATER_COUNT (4 bit field) 

This field is coded as the binary representation of the PSI3 quater index (in the PSI3 quater message) for the last 

(highest indexed) individual PSI3 quater message. 

Range: 0-15. 

GPRS REP PRIORITY Description 

REP_PRIORITY bit: 

Normal reporting priority 

1 High reporting priority 

The use of these bits is defined in sub-clause 5.6.3.5 ("GPRS Report Priority Description"). 
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3G Neighbour Cell Description 

The building of the 3G Neighbour Cell list and the ordering of indices within each Radio Access Technology is 
described in sub-clause 5.6.3.1. 

Index_Start_3G (7 bit) 

This optional information element indicates the value of the first index to use to build this instance of the 3G Neighbour 
Cell list. When missing, the value is assumed. See sub-clause 5.6.3.1. 

Absolute_Index_Start_EMR (7 bit) 

This parameter indicates the value to be added to the indexes of the 3G Neighbour Cell list for reporting 3G Cells with 
the PACKET ENHANCED MEASUREMENT REPORT message (see sub-clause 5.6.3.3). If different values are 
received for this parameter in different instances of this message, the instance with the highest index shall be used. 

NOTE: This parameter is not used for reporting 3G Cells with the PACKET MEASUREMENT REPORT 

message, see sub-clause 11.2.9. 

UTRAN FDD Description: 

For detailed element definitions see the Packet Measurement Order message with the following exception for the 
FDD_CELL_INFORMATION Field: 

FDD_CELL_INFORMATION Field (p bit field) 

If parameter n in table 1 1.2. 9b. 2. a is equal to 31, this indicates that the corresponding UARFCN shall be included in the 
GPRS 3G Cell Reselection list (see sub-clause 5.6.3.7); no index shall be allocated in the 3G Neighbour Cell list. 

UTRAN TDD Description: 

For detailed element definitions see the Packet Measurement Order message with the following exception for the 
TDD_CELL_INFORMATION Field: 

TDD_CELL_INFORMATION Field (q bit field) 

If parameter m in table 1 1.2.9b.2.b is equal to 31, this indicates that the corresponding UARFCN shall be included in 
the GPRS 3G Cell Reselection list (see sub-clause 5.6.3.7); no index shall be allocated in the 3G Neighbour Cell list. 

3G MEASUREMENT PARAMETERS Description 

The fields of this Description are used for measurements as defined in 3GPP TS 45.008. 

3G Initial Dedicated Mode Reporting Description 

These parameters shall only be used in initial 3G neighbour cell reporting in dedicated mode. 

3G_BA_IND (1 bit field) 

The 3G_BA_IND is needed to identify set of 3G Neighbour Cell information used for reporting in dedicated mode. The 
value received is reflected in the MEASUREMENT REPORT and ENHANCED MEASUREMENT REPORT 
messages, see 3GPP TS 44.018 'Parameters for Measurements and Reporting'. 

The other fields of this Description are used for measurements as defined in 3GPP TS 45.008. 

GPRS 3G Additional Measurement Parameters Description 

The fields of this Description are used for measurements as defined in 3GPP TS 45.008. 
If the GPRS 30 Additional MeasurementParameters Description is included in more than one instance of the 
PSBquater message, the GPRS 3G Additional MeasurementParameters Description of the instance with the highest 
PSI3quater_INDEX shall be used. 

3G_CCN_ACTIVE (1 bit field) 

This field indicates whether CCN is enabled towards 3G neighbouring cells. It is coded as follows: 

CCN towards 3G cells is disabled in the cell. 

1 CCN towards 3G cells is enabled in the cell. 
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GPRS 3G Additional Measurement Parameters Description 2 

The fields of this Description are used for measurements as defined in 3GPP TS 45.008. 

If the GPRS 3G Additional Measurement Parameters Description 2 is included in more than one instance of the 
PSBquater message, the GPRS 3G Additional Measurement Parameters Description 2 of the instance with the highest 
PSI3quater_INDEX shall be used. 



1 1 .2.21 b.1 GPRS REP PRIORITY description 

A GPRS REP PRIORITY description construction shall be included in one and only one instance of the PACKET 
SYSTEM INFORMATION TYPE 3 QUATER message within the consistent set of PACKET SYSTEM 
INFORMATION TYPE 3 QUATER messages. 

11.2.22 (void) 

1 1 .2.23 Packet System Information Type 5 

This optional message is sent by the network on the PBCCH giving information for measurement reporting and network 
controlled cell reselection. This message shall not be segmented across more than one RLC/MAC control block by 
using the procedures specified in sub-clause 9.1.12a. If not all information fits into one message, the remaining 
information will be sent in other instances of the PSI5 message. The message is sent on PBCCH only if so indicated in 
PSIl. 

Message type: PACKET SYSTEM INFORMATION TYPE 5 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.23.1: PSI5 information elements 

< PSI5 message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI5_CHANGE_MARK : bit (2) > 

< PSI5JNDEX : bit (3) > 

< PSI5_C0UNT : bit (3) > 

{ I 1 < NC Measurement Parameters : < NC IVIeasurement Parameters struct > > } 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 
{ null I bit** = <no string> -- Receiver backward compatible with earlier version 

1 1 -- Additional contents for Release '99 

{ I 1 < ENH Reporting Parameters : < ENH Reporting Parameters struct » } 
{ null I bit** = <no string> -- Receiver compatible with earlier release 

I 1 -- Additions in REL-5: 

{ I 1 < GPRS 3G Additional Measurement Parameters Description 2 : 

< GPRS 3G Additional Measurement Parameters Description 2 struct » } 

< padding bits > } } 

! < Distribution part error : bit (*) = < no string > > ; 

< NO Measurement Parameters struct > ::= 

< NETWORK_CONTROL_ORDER : bit (2) > 
{ I 1 < NC_ NON_DRX_PERIOD : bit (3) > 

< NC_REPORTING_PERIOD_l : bit (3) > 

< NC_REPORTING_PERIOD_T : bit (3) > } ; 

< ENH Reporting parameters struct > ::= 

< Report_Type : bit > 

< REPORTING_RATE : bit > 

< INVALID_BSIC_REPORTING : bit > 
{ I 1 < NCC_PERMITTED : bit (8) > } 

{ I 1 < GPRS MEASUREMENT Parameters Description : 

< GPRS MEASUREMENT Parameters Description struct » } 
{ I 1 < GPRS 3G MEASUREMENT Parameters Description : 

< GPRS 3G MEASUREMENT Parameters Description struct» } ; 

< GPRS MEASUREMENT PARAMETERS Description struct > ::= 

{ I 1 < MULTIBAND_REPORTING : bit (2) > } 
{ I 1 < SERVING_BAND_REPORTING : bit (2) > } 
{ I 1 < SCALE_ORD : bit (2) > } 

{ I 1 < 900_REPORTING_OFFSET : bit (3) > 

< 900_REPORTING__THRESHOLD : bit (3) > } 

{ I 1 < 1800_REPORTING_OFFSET : bit (3) > 

< 1800_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 400_REPORTING_OFFSET : bit (3) > 

< 400_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 1900_REPORTING_OFFSET : bit (3) > 

< 1900_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < 850_REPORTING_OFFSET : bit (3) > 

< 850_REPORTING_THRESHOLD : bit (3) > } ; 

< GPRS 3G MEASUREMENT PARAMETERS Description struct > ::= 

{ I 1 < FDD_REP_QUANT : bit > -- FDD Parameters 

< FDD_MULTIRAT_REPORTING : bit (2) > } 
{ I 1 < FDD_REPORTING_OFFSET : bit (3) > 

< FDD_REPORTING_THRESHOLD : bit (3) > } 

{ I 1 < TDD_MULTIRAT_REPORTING : bit (2) > } - TDD Parameters 

{ I 1 < TDD_REPORTING_OFFSET : bit (3) > 

< TDD_REPORTING_THRESHOLD : bit (3) > } ; 

< GPRS 3G Additional Measurement Parameters 2 struct > ::= 

{ I 1 < FDD_REP0RTING_THRESH0LD_2 : bit (6) > } ; -- FDD Parameters 
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Table 11.2.23.2: PSI5 information element details 

The optional PSI5 message contains broadcast measurement parameters for Network Control (NC) measurements 
containing the NC Measurement Parameters. The NC Measurement parameters struct shall only exist in one instance of 
the PSI5 message. If the NC Measurement parameters struct is included in more than one instance, the value of the 
struct in the instance with the highest index shall be valid and all others shall be ignored. 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PSI5_CHANGE_MARK (2 bit field) 

The PSI5_CHANGE_MARK field is changed each time information has been updated in any of the individual 
instances of the PSI5 message. A new value indicates that the mobile station shall re-read the information from all PSI5 
messages. Range: to 3. The coding of this field is network dependent. 

PSI5_INDEX (3 bit field) and PSI5_COUNT (3 bit field) 

The purpose of the PSI5_INDEX field and the PSI5_COUNT field is to indicate the number of individual messages 
within the sequence of PSI5 messages and to assign an index to identify each one of them. The PSI5_INDEX field is 
binary coded, range: to 7, and provides an index to identify the individual PSI5 message. The PSI5_COUNT field is 
binary coded, range: to 7, and provides the PSI5_INDEX value for the last (highest indexed) message in the sequence 
of PSI5 messages. 

NETWORK_CONTROL_ORDER (2 bit field) 

The NETWORK_CONTROL_ORDER field is coded according to the following table (for definition of NCx see 

3GPPTS 45.008): 



bit 




2 1 




00 


NCO 


01 


NCI 


10 


NC2 


1 1 


Reserved 



If the NETWORK_CONTROL_ORDER parameter = NCO, then the other parameters in the NC Measurement 
parameters struct may be omitted. If the NETWORK_CONTROL_ORDER parameter indicates NCI or NC2 and the 
other parameters are omitted, the default value for these parameters shall be assumed. 

NC_NON_DRX_PERIOD (3 bit field) 

This field indicates the minimum time the mobile station shall stay in non-DRX mode after an NC-measurement report 

has been sent. The field is coded according to the following table: 



bit 




321 




000 


No non-DRX mode after a measurement report has been sent 


001 


0,24 s 


010 


0,48 s (default value) 


01 1 


0,72 s 


100 


0,96 s 


101 


1,20 s 


1 10 


1,44 s 


1 1 1 


1,92 s 
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NC_REPORTING_PERIOD_I (3 bit field) 

NC_REPORTING_PERIOD_T (3 bit field) 

These fields indicate the time period for cell reselection measurement reporting for packet idle mode (I) and packet 

transfer mode (T), respectively. The field is coded according to the following table: 

bit 

321 

0,48 s 

1 0,96 s 

1 1,92 s 

1 1 3,84 s (default value for NC_REPORTING_PERIOD_T) 

1 7,68 s 
101 15,36 s 
1 1 30,72 s 

1 1 1 61,44 s (default value for NC_REPORTING_PERIOD_I) 

NCC_PERMITTED (8 bit field) 

This field is a bitmap of NCCs for which the mobile station is permitted to report measurement; this bitmap relates to 

NCC part of BSIC (see coding field in 3GPP TS 44.018). 

ENH Reporting Parameters (Enhanced Measurement reporting parameters) 

Report_Type (Ibit) 

This parameter is used to indicate to the mobile station to use the PACKET ENHANCED MEASUREMENT REPORT 

message or the PACKET MEASUREMENT REPORT message for (NC) reporting: 

Bit 

The MS shall use the PACKET ENHANCED MEASUREMENT REPORT message for (NC) reporting 

1 The MS shall use the PACKET MEASUREMENT REPORT message for (NC) reporting. 

REPORTING_RATE (1 bit) 

This parameter is used for measurements, see 3GPP TS 45.008. 

Bit 

normal rate reporting 

1 Reduced reporting rate allowed. 

INVALID_BSIC_REPORTING (1 bit) 

This field specifies if cells with invalid BSIC and allowed NCC part of BSIC are allowed to be reported or not, see 

3GPPTS 45.008. 

Bit 

Report on cells with invalid BSIC and allowed NCC part of BSIC is not allowed. 

1 Report on cells with invalid BSIC and allowed NCC part of BSIC is allowed. In this case NCC_PERMITTED is 
required. 

GPRS MEASUREMENT PARAMETERS Description 

The fields of this Description are used for measurements as defined in 3GPP TS 45.008. 

GPRS 3G MEASUREMENT PARAMETERS Description 

The fields of this Description are used for measurements as defined in 3GPP TS 45.008. 

GPRS 3G Additional Measurement Parameters 2 Description 

The fields of this Description are used for measurements, as defined in 3GPP TS 45.008. 



1 1 .2.23a Packet System Information Type 6 



This optional message is sent by the network on the PBCCH or PACCH to provide broadcast information required by 
non-GSM networks. This message shall not be segmented across more than one RLC/MAC control block by using the 
procedures specified in sub-clause 9.1.12a. If not all information fits into one instance of the PSI6 message, the PSI6 
message can be repeated.. Special requirements for the transmission of this message apply on PBCCH, see 
3GPP TS 45.002. 
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Message type: PACKET SYSTEM INFORMATION TYPE 6 
Direction: network to mobile station 

Classification: distribution message 

Table 11. 2.23a.1: PSI6 information elements 

< PSI6 message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI6_CHANGE_MARK : bit (2) > 

< PSI6JNDEX : bit (3) > 

< PSI6_C0UNT : bit (3) > 

{ {< NonGSM Message : < Non-GSIVI IVIessage struct > > ** 

-- The Non-GSIVI Message struct is repeated until: 

{ < spare bit > *3 00000 } -- A) val(NR_OF_CONTAINER_OCTETS) = 0, or 

< padding bits > } // -- B) the PSI message is fully used 

! < Distribution part error : bit (*) = < no string > > ; 

< NonGSIVI Message struct > ::= 

< NonGSM Protocol Discriminator : bit(3) > 

< NR_OF_CONTAINER_OCTETS : bit(5) exclude 00000 } > 

{ < CONTAINER : bit{8) > } * (val{NR_OF_CONTAINER_OGTETS)) ; 



Table 11. 2.23a.2: PSI6 information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PSI6_CHANGE_MARK (2 bit field) 

The PSI6 change mark field is changed each time information has been updated in any of the PSI6 messages. A new 
value indicates that the mobile station shall re-read the information from the PSI6 message. The coding of this field is 
network dependent. 

Range: 0-3. 

PSI6_INDEX (3 bit field) and PSI6_COUNT (3 bit field) 

The purpose of the PSI6_INDEX field and the PSI6_COUNT field is to indicate the number of individual messages 
within the sequence of PSI6 messages and to assign an index to identify each one of them. The PSI6_INDEX field is 
binary coded, range: to 7, and provides an index to identify the individual PSI6 message. The PSI6_COUNT field is 
binary coded, range: to 7, and provides the PSI6_INDEX value for the last (highest indexed) message in the sequence 
of PSI6 messages. 

NonGSM Protocol Discriminator (3 bit field) 

This information element is used to identify the non-GSM network for which a PSI6 message is transmitted and is 

coded as shown below. 

Bit 

321 

00 1 TIA/EIA-136 

All other values are reserved 
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NR_OF_CONTAINER_OCTETS (5 bit field) 

This field indicates the number of CONTAINER octets that forms a specific non-GSM message and is coded as shown 
below. 

Bit 

5432 1 

1 CONTAINER length is 1 octet 

10 CONTAINER length is 2 octets 

.... through . . . 

10 11 CONTAINER length is 19 octets 

11111 The remaining portion of the PSI message is used by the associated CONTAINER. The Non-GSM 

message continues in a subsequent instance of the PSI message, in the next CONTAINER with the same 

Non-GSM Protocol Discriminator value as the current one. 
All other values are reserved. 

CONTAINER (8 bits) 

The concatenation of one or several CONTAINER octets forms the actual contents, specific to the non-GSM network 
soliciting the transmission of a PSI6 message. 



1 1 .2.23b Packet System Information Type 7 



This optional message is sent by the network on the PBCCH or PACCH to provide broadcast information required by 
non-GSM networks. This message shall not be segmented across more than one RLC/MAC control block by using the 
procedures specified in sub-clause 9.1.12a. If not all information fits into one instance of the PSI7 message, the PSI7 
message can be repeated.. Special requirements for the transmission of this message apply on PBCCH, see 
3GPPTS 45.002. 

Message type: PACKET SYSTEM INFORMATION TYPE 7 

Direction: network to mobile station 

Classification: distribution message 

The PSI7 information elements are equal to the PSI6 elements defined in sub-clause 11.2.23a. 



1 1 .2.24 Packet System Information Type 8 



This message is optionally sent by the network on the PBCCH and PACCH giving information about Cell Broadcast 
Channel configuration and Dynamic ARFCN Mapping. This message shall not be segmented across more than one 
RLC/MAC control block by using the procedures specified in sub-clause 9. 1 . 12a. Special requirements for the 
transmission of this message apply on PBCCH, see 3GPP TS 45.002. 

Message type: PACKET SYSTEM INFORMATION TYPE 8 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.24.1: PSI8 information elements 

< PSI8 message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI8_CHANGE_MARK : bit (2) > 

< PSI8JNDEX : bit (3) > 

< PSI8_C0UNT : bit (3) > 

{ I 1 < CBCH Channel Description : < CBCH Channel Description struct > >} 
{ null I bit** = < no string > 

I 1 -- Release 4 additions: 

{ I 1 < Dynamic ARFCN Mapping Description : < Dynamic ARFCN IVIapping Description struct > > } 

< padding bits >} 

! < Distribution part error : bit (*) = < no string > > ; 

< CBCH Channel Description struct > ::= 

< Channel type and TDMA offset : bit (5) > 

< TN : bit (3) > 

< Frequency Parameters : < Frequency Parameters IE > > ; 

< Dynamic ARFCN IVIapping Description struct > ::= 

{ I 1 < DM_CHANGE_MARK : bit (4) > } 
{ 1 < DYNAMIC ARFCN MAPPING > } ** ; 

< DYNAMIC ARFCN MAPPING >::= 

< GSM_Band : bit (4) > 

< ARFCN_FIRST : bit (10) > - - Dynamic ARFCN mapping parameters 

< BAND_OFFSET: bit (10) > 

< ARFCN_RANGE : bit (7) > ; 



Table 11.2.24.2: PSI8 information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PSI8_INDEX (3 bit field) and PSI8_COUNT (3 bit field) 

These fields are the binary representation of the PSI index and PSI cownf parameters associated with the PSI8 messages. 

PSI8_CHANGE_MARK (2 bit field) 

The PSI8 change mark field is changed each time information has been updated in the PSI8 message. A new value 
indicates that the mobile station shall re-read the information from the PSI8 message. The coding of this field is 
network dependent. Range: 0-3. 

CBCH Channel Description struct 

The CBCH Channel Description provides the description for the CBCH. If the CBCH Channel Description is not 
available (either as it is not included in any instance of PSI8 or as no PSI8 is broadcast at all), the mobile station can 
assume that SMSCB is not active in the cell. If available, the CBCH Channel Description construction shall be included 
in one and only one instance of the PSI8 message within the consistent set of PSI8 messages 

Channel type and TDMA offset (5 bit field) 

For encoding and description see 3GPP TS 44.018 . 

TN, Timeslot number(3 bit field) 

The TN field is coded as the binary representation of the timeslot number as defined in 3GPP TS 45.002. 

DM_CHANGE_MARK (4 bit field). Dynamic ARFCN Mapping Change Mark. 

This parameter is used to indicate to the MS a change of information concerning Dynamic ARFCN Mapping. This field 
shall be present in only one instance of Dynamic ARFCN Mapping Description struct in a consistent set of PSI8 
messages. 
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Dynamic ARFCN Mapping parameters description: 

These parameters allow to allocate ARFCN values and then dynamically map to physical frequencies, see 
3GPP TS 45.005. The parameters of this description are defined in 3GPP TS 44.018. 

If the mobile station receives more than 8 DYNAMIC_ARFCN_MAPPING structures, it shall store at least the 8 first 
structures in the order of occurrence, starting with the PSI8 instance with the lowest index number. 



1 1 .2.25 Packet System Information 1 3 

This message may be broadcast by the network on the PACCH or on the PCCCH (see sub-clause 5.5.2.1). The message 
provides the mobile station with GPRS cell specific access-related information. The information in this message shall 
be the same as provided in the SI13 message on BCCH, see 3GPP TS 44.018. This message shall not be segmented 
across more than one RLC/MAC control block by using the procedures specified in sub-clause 9.1.12a. 

Message type: PACKET SYSTEM INFORMATION TYPE 1 3 

Direction: network to mobile station 

Classification: distribution message 

Table 11.2.25.1: PSI13 information elements 

< PSI13 message content > ::= 

< PAGE_MODE : bit (2) > 

< BCCH_CHANGE_MARK : bit (3) > 

< SI_CHANGE_FIELD : bit (4) > 

{0|1 <SI13_CHANGE_MARK:bit{2)> 

< GPRS Mobile Allocation : < GPRS Mobile Allocation IE > > } 
{ - PBCCH not present in cell : 

< RAC : bit (8) > 

< SPGC_CCCH_SUP : bit > 

< PRIORITY_ACCESS_THR : bit (3) > 

< NETWORK_CONTROL_ORDER : bit (2) > 

< GPRS Cell Options : < GPRS Cell Options IE > > 

< GPRS Power Control Parameters : < GPRS Power Control Parameters IE > > 
I 1 - PBCCH present in cell : 

< PSI1_REPEAT_PERI0D : bit (4) > 

< PBCCH Description : < PBCCH Description struct > > } 

{ null I bit** = < no string > - Receiver compatible with ealier release 

I 1 ~ Additions in release 99 : 

< SGSNR : bit > 

{ null I bit** = < no string > - Receiver compatible with earlier release 

I 1 ~ Additions in release R4 : 

< SLSTATUSJND : bit > 

{ null I bit** = < no string > - Receiver compatible with earlier release 

I 1 - Additions in Rel-6: 

{ 11 < LB_MS_TXPWR_MAX_CCH : bit (5) > } 

< SI2n_SUPP0RT: bit (2) > 

< padding bits > } } } 

! < Distribution part error : bit (*) = < no string > > ; 

< PBCCH Description struct > ::= 

< Pb : bit (4) > 

< TSC : bit (3) > 

< TN : bit (3) > 

{ - default to BCCH carrier 

I 10 < ARFCN : bit (10) > 

I 1 1 < MAIO : bit (6) > } ; 
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Table 11.2.25.2: PSI13 information element details 

PAGE_MODE (2 bit field) 

This field describes which type of page mode used, i.e. either normal paging, extended paging, paging reorganization or 
same as before from the previous page mode. The mobile station shall ignore this field if the message is received on the 
PACCH. Coding of this field is defined in 3GPP TS 44.018. 

BCCH_CHANGE_MARK (3 bit field) 

This field indicates the status of the information on BCCH. The value of this field shall be changed each time the 

information on BCCH, except for the contents of the SI-13 message, is changed. 

SI_CHANGE_FIELD (4 bit field) 

This field is the binary representation of which information was changed at the last indication in 

BCCH_CHANGE_MARK. Range to 15: 

bit 

4321 

Update of unspecified SI message or SI messages; 

1 Update of SIl message; 

10 Update of SI2, SI2 bis or SI2 ter message; 

11 Update of SI3, SI4, SI7 or SIS message; 

10 Update of SI9 message; 

10 1 Update of SI18 or SI20 message; 

110 Update of SI19 message;0 1 1 lUpdate of SI15 message; 

10 Update of SI2n message; 

All other values shall be interpreted as 'update of unknown SI message type'. 

SI13_CHANGE_MARK (2 bit field) 

This field is the binary representation of the SI change mark identifying the GPRS Mobile Allocation provided in SI 13 

and PSI13 messages. 

Range: to 3. 

GPRS Mobile Allocation (information element) 

This information element is the representation of the GPRS mobile allocation provided in SI13 and PSI13 messages. It 
is identified by MA_NUMBER = 14 when referenced from a packet assignment message. When used in SI13 or PSI13 
message, this information element shall refer to the cell allocation defined for the cell in SIl or PSI2. 

RAG (8 bit field) 

This field is the binary representation of the Routing Area Code, see 3GPP TS 23.003. 

SPGC_CCCH_SUP (bit field) 

This field indicates the support of the parameter SPLIT_PG_CYCLE on CCCH from the network side: 

SPLIT_PG_CYCLE is not supported on CCCH in this cell; 

1 SPLIT_PG_CYCLE is supported on CCCH in this cell. 

The PRIORITY_ACCESS_THR field (3 bit) is the binary representation of the parameter 
PRIORITY_ACCESS_THR: 

bit 

321 

packet access is not allowed in the cell; 

1 spare, shall be interpreted as '000' (packet access not allowed); 

10 spare, shall be interpreted as '000' (packet access not allowed); 

Oil packet access is allowed for priority level 1 ; 

10 packet access is allowed for priority level 1 to 2; 

10 1 packet access is allowed for priority level 1 to 3; 

110 packet access is allowed for priority level 1 to 4; 

111 spare, shall be interpreted as '1 10' (packet access allowed). 
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The NETWORK_CONTROL_ORDER field (2 bit) is the binary representation of the parameter 
NETWORK_CONTROL_ORDER, see 3GPP TS 45.008: 

bit 
2 1 

NCO: MS controlled cell re-selection, no measurement reporting. 

1 NCI: MS controlled cell re-selection, MS sends measurement reports. 

1 NC2: Network controlled cell re-selection, MS sends measurement reports. 
1 1 Reserved for future use, interpreted as NCO by mobile station. 

GPRS Cell Options (information element) 

The GPRS Cell Option information element is defined in sub-clause 12.24. 

PSIl_REPEAT_PERIOD (4 bit field) 

This field is the representation of the PSIl repeat period. The field is coded according to the following table: 

bit 

4321 

PSIl repeat period = 1 multiframe 

1 PSIl repeat period = 2 multiframes 

1111 PSIl repeat period = 16 multiframes 

GPRS Power Control Parameters (information element) 

The GPRS Power Control Parameters information element is defined in sub-clause 12.09a. 

PBCCH Description struct 

The PBCCH description struct provides the channel description for the PBCCH. The frequency description for the 
PBCCH may be specified by an ARFCN (non-hopping radio frequency channel) or a MAIO (hopping radio frequency 
channel) field. In case of a hopping radio frequency channel, the PBCCH shall use the GPRS mobile allocation 
specified in this message. If none of the ARFCN or MAIO fields are present, the PBCCH shall use the BCCH carrier. 

Pb (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 

TSC (3 bit field) 

This field is the binary representation of the training sequence code used for PBCCH. 

Range: to 7. 

TN (3 bit field) 

This field is the binary representation of the timeslot number for the PBCCH. 

Range: to 7. 

ARFCN (10 bit field) 

This field is the binary representation of the absolute RE channel number. 

Range: to 1023. 

MAIO (6 bit field) 

This field is the binary representation of the mobile allocation index offset. 

Range: to 63. 

SGSNR (bit field) 

This field indicates the Release of the SGSN: 

SGSN is Release '98 or older 

1 SGSN is Release '99 onwards. 

SI_STATUS_IND (1 bit field): 

The network does not support the PACKET SI STATUS message; 

1 The network supports the PACKET SI STATUS message. 
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LB_MS_TXPWR_MAX_CCH (5 bit field) 

The LB_MS_TXPWR_MAX_CCH field is coded as the binary representation of the 'power control level' in 

3GPP TS 45.005 corresponding to the maximum TX power level a mobile station may use when accessing on a packet 

control channel. This value shall be used by the mobile station according to 3GPP TS 45.008. 

SI2ii_SUPPORT (2 bit field) 

This field indicates the support of SI2n in the network, see 3GPP TS 44.018. 



1 1 .2.25a Packet System Information 14 

This message may be sent by the network on the PACCH. The message may provide a mobile station in dual transfer 
mode or the in Network Assisted Cell Change procedure with GPRS access-related information. The information may 
be used as a substitute for the SI13 (and in some cases, the SIl) message on BCCH after the release of an RR 
connection, see 3GPP TS 44.018. This message may also be used during dual transfer mode to inform the mobile 
station about possible changes in the SI or PSI messages. This message may also be used in the network assisted cell 
change procedure when the target cell has PBCCH present. 

Message type: PACKET SYSTEM INFORMATION TYPE 14 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.25a.1: PSI14 information elements 



< PSI14 message content > ::= 




< PAGE_MODE : bit (2) > 




{ < CCCH Access Information : < CCCH Access Information struct » 


1 1 < PBCCH Description : < PBCCH Description struct 2 


» 


< padding bits > } 




! < Distribution part error : bit (*) = < no string » ; 




< CCCH Access Information struct > ::= 




< BCCH CHANGE MARK : bit (3) > 




{0|1 <SI13_CHANGE_IVIARK:bit(2)> 




< SI13 Mobile Allocation : < GPRS IVIobile Allocation IE » } 


< SPGC CCCH SUP : bit > 




< PRIORITY ACCESS THR : bit (3) > 




< NETWORK_CONTROL_ORDER : bit (2) > 




< GPRS Cell Options : < GPRS Cell Options IE » 




< GPRS Power Control Parameters : < GPRS Power Control Parameters struct » | 


< SGSNR : bit > 




{ null 1 bit ** = < no string > 


-- Receiver backward compatible witii earlier version 


M 


-- Additions for Dual Transfer l\/lode 





-- compatible witli earlier version 


< RAC : bit (8) > 




< SLSTATUSJND : bit > 




{ null 1 bit ** = < no string > 


-- Receiver backward compatible witfi earlier version 


M 


-- Additions for Rei-6 


{ 1 1 < LB MS TXPWR MAX CCH : bit (5) > } 




<SI2n SUPPORT : bit (2) > 

} 

}; 




< PBCCH Description struct 2 > ::= 




< PSI1 REPEAT PERIOD : bit (4) > 




< Pb : bit (4) > 




< TN : bit (3) > 




< PBCCH Frequency Description : < Frequency Parameters IE » 


{ null 1 bit ** = < no string > 


-- Receiver backward compatible witli earlier version 


M 


-- Additions for Dual Transfer Mode 


1 


-- compatible witti earlier version 


< RSI CHANGED IND : bit > 




}; 





Table 11.2.25a.2: PSI14 information element details 



PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

BCCH_CHANGE_MARK (3 bit field) 

This field indicates the status of the information on BCCH. The value of this field shall be changed each time the 

information on BCCH, except for the contents of the SI13 message, is changed, see sub-clause 5.5.2.1.4. 

SI13_CHANGE_MARK (2 bit field) 

This field is the binary representation of the SI change mark identifying the GPRS Mobile Allocation provided in SI13 

and PSI13 messages. Range: to 3. 

SI13 Mobile Allocation 

This field is encoded using the GPRS Mobile Allocation information element defined in sub-clause 12.10a. This 
information shall be identical with the GPRS mobile allocation provided in SI13 and PSI13 messages. 

SPGC_CCCH_SUP (1 bit field) 

This field is defined in the SI13 message, see 3GPP TS 44.018. 
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PRIORITY_ACCESS_THR (3 bit field) 

This field is defined in the SI13 message, see 3GPP TS 44.018. 

NETWORK_CONTROL_ORDER (2 bit field) 

This field is defined in the SI13 message, see 3GPP TS 44.018. 

GPRS Cell Options (information element) 

The GPRS Cell Option information element is defined in sub-clause 12.24. 

SGSNR(1 bit field) 

This field is defined in the SI13 message, see 3GPP TS 44.018. 

GPRS Power Control Parameters (information element) 

The GPRS Power Control Parameters information element is defined in sub-clause 12.9a. 

PSIl_REPEAT_PERIOD (4 bit field) 

This field is the binary representation, range to 15, of the PSIl repeat period. The coding of this field is identical to 

the coding of the PSIl_REPEAT_PERIOD field in the PSIl message. 

Pb (4 bit field) 

This is the binary representation, range to 15, of the power reduction value used by the BTS on PBCCH blocks, 

relative to the output power on BCCH, see 3GPP TS 45.008. 

TN (3 bit field) 

This is the binary representation, range to 7, of the timeslot number for the PBCCH, see 3GPP TS 45.002. 

PBCCH Frequency Description 

The PBCCH frequency description is encoded using the Frequency Parameters information element defined in sub- 
clause 12.8. When used in this message, the Frequency Parameters information element shall define a non-hopping 
radio frequency channel or use the direct encoding 2 to define a hopping radio frequency channel. 

RAC (8 bit field) 

This field is the binary representation of the Routing Area Code, see 3GPP TS 23.003. 

PSI_CHANGED_IND (1 bit field) 

This field indicates whether the contents of any PSI message have been changed, see sub-clause 5.5.2.1.3. 
If not included in the message, the value "0" shall be assumed. 

SI_STATUS_IND (1 bit field) 

The network does not support the PACKET SI STATUS message; 

1 The network supports the PACKET SI STATUS message. 
If not included in the message, the value "0" shall be assumed. 

LB_MS_TXPWR_MAX_CCH (5 bit field) 

The LB_MS_TXPWR_MAX_CCH field is coded as the binary representation of the 'power control level' in 

3GPP TS 45.005 corresponding to the maximum TX power level a mobile station may use when accessing on a packet 

control channel. This value shall be used by the mobile station according to 3GPP TS 45.008. 

SI2n_SUPPORT (2 bit field) 

This field indicates the support of SI2n in the network, see 3GPP TS 44.018. 



1 1 .2.25b Packet System Information 1 5 

This message may be sent by the network on the PACCH. It may be sent to a mobile station with UTRAN capability. A 
mobile station ith no UTRAN capability shall ignore this message. 

The message provides the mobile station with a list of the UTRAN frequencies used by the network. These frequencies 
may be used in the cell selection procedure, see 3GPP TS 25.304. If both an UTRAN Frequency List Description struct 
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and an UTRAN Frequency List information element (3GPP TS 44.018) are received, the mobile station shall use the 
one most recently received. 

Message type: PACKET SYSTEM INFORMATION TYPE 15 

Direction: network to mobile station 

Classification: distribution message 

Table 11. 2.25b. 1: PSI15 information elements 



< PSI15 message content > ::= 

< PAGE_MODE : bit (2) > 

{ I 1 < UTRAN Frequency List : < UTRAN Frequency List Description struct » } 

< padding bits > 

I < Distribution part error : bit (*) = < no string » ; 



< UTRAN Frequency List Description struct > ::= 

{ 1 < FDD_ARFCN > : bit (14) } ** -- FDD frequencies 
{ 1 < TDD_ARFCN > : bit (1 4) } ** ; -- TDD frequencies 



Table 11.2.25b.2: PSI15 information element details 



PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

UTRAN Frequency List Description struct 

FDD_ARFCN and TDD_ARFCN (14 bits field) are defined as the UARFCN in 3GPP TS 25.101 and 
3GPPTS 25.102. 



1 1 .2.25c Packet System Information Type 1 6 

This message is sent by the network on the PBCCH and the PACCH giving information about lu mode operation. 
Special requirements for the transmission of this message apply on the PBCCH, see 3GPP TS 45.002. 

This message shall not be segmented across more than one RLC/MAC control block by using the procedures specified 
in sub-clause 9.1.12a. A consistent set of this message type is required to completely decode the information (see sub- 
clause 5.5.2.1.4). 

Message type: PACKET SYSTEM INFORMATION TYPE 16 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.25c.1: PSI16 information elements 

< PSI16 message content > ::= 

< PAGE_MODE : bit (2) > 

< PSI16_CHANGE_MARK : bit (2) > 
<PSI16JNDEX:bit(3)> 
<PSI16_COUNT:bit(3)> 

< GRA_ID_LIST : < GRA ID struct > > 

< lu_MODE_NMO_SUPPORT : bit (1 ) > 

< CN_DOMAIN_LIST : bit (2) > 

{ < CN_DOMAINJDENTITY : < CN Domain Identity IE > > 

< CN DOMAIN SPECIFIC DRX CYCLE LENGTH COEFFICIENT : < CN Domain Specific DRX Cycle Length 
Coefficient IE > > 

} * (1+val(CN_D0IVIAIN_LIST)) 

{0| 1 <3G_LAC:bit(16)>} 

{ I 1 < 3G_RAC : bit (8) > } 

{ I 1 < GRA_AND CELL UPDATE TIMER : bit (3) > } 

< padding bits > 

I < Distribution part error : bit (*) = < no string » ; 
<GRAID struct > ::= 

< NUMBER_OF_GRAJDs : bit (3) > 

{ < GRAJD : bit (16) > } * (1 + val(NUMBER_OF_GRA_IDs)); 

Table 11.2.25c.2: PSI16 information element details 

PAGE_MODE (2 bit field) 

This field describes which type of page mode used, i.e. either normal paging, extended paging, paging reorganization or 
same as before from the previous page mode. The mobile station shall ignore this field if the message is received on the 
PACCH. Coding of this field is defined in 3GPP TS 44.018 

PSI16_CHANGE_MARK (2 bit field) 

This field is the binary representation of the PSI change mark parameter identifying a consistent set of PSI16 messages. 

Range: to 3. 

PSI16_INDEX (3 bit field) 

The PSI16 index field is used to distinguish individual PSI16 messages. The field can take the binary representation of 

the values to n, where n is the index of the last PSI16 message. (PSI16 count). 

Range: 0-7. 

PSI16_COUNT (3 bit field) 

The PSI16 count field is coded as the binary representation of the last (highest indexed) individual PSI16 message. 

Range: 0-7. 

GERAN Id struct 

At least one GRA Id shall be broadcast in each cell. Maximum number is eight. 

NUMBER_OF_GRA_IDs (3 bit field) 

The NUMBER of GRA Ids field is coded as the binary representation of the amount of GRA IDs sent in an individual 

PSI16 message. 

Range: 0-7. 

GRAJD (16 bit field) 

The GRAJD defines the indentity of a GERAN Registration Area Identity to which the cell belongs. 

Iu_MODE_NMO_SUPPORT (1 bit field) 

This parameter is used for determining network mode of operation for the 3G SGSN and the 3G MSC. The mobile 

station may assume that the network has set this field equally in all instancies of this message. 

Bit 

Network Mode Operation I 

1 Network Mode Operation II 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 309 ETSI TS 144 060 V6.28.0 (2010-03) 



CN_DOMAIN_LIST (2 bit field) 

This field is used to repeat information for each CN domain. Range : to MaxCNdomains-1, see 3GPP TS 44.1 18. 

CN_DOMAIN_IDENTITY 

This IE is defined in 3GPP TS 44.1 18. 

CN_DOMAIN_SPECIFIC_DRX_CYCLE_LENGTH_COFFICIENT 

This IE is defined in 3GPP TS 44.1 18. 

3G_LAC (16 bit field) 

This field is only broadcast if the cell supports lu mode and if 2G and 3G are using different location area codes. The 

coding of 3G_LAC is presented in 3GPP TS 23.003. 

3G_RAC (8 bit field) 

This field is only broadcast if the cell supports lu mode and if 2G and 3G are using different routing area codes. The 

coding of 3G_RAC is presented in 3GPP TS 23.003. 

GRA_AND_CELL_UPDATE_TIMER (3 bit field) 

This field is the binary representation of GRA and CELL UPDATE TIMERs. 

bit 

321 

5 minutes 

1 10 minutes 

10 30 minutes (default value) 

Oil 60 minutes 

10 120 minutes 

10 1 360 minutes 

110 720 minutes 

111 Infinity (no update) 



1 1 .2.26 Packet TBF Release 

This message is sent on the PACCH by the network to the mobile station to initiate release of an uplink or downlink 
TBF. 

Message type: PACKET TBF RELEASE 

Direction: network to mobile station 

Classification: non-distribution message 

Table 11.2.26.1: PACKET TBF RELEASE information elements 



< Packet TBF Release message content > ::= 




< PAGE MODE : bit (2) > 




{ < GLOBAL TFI : Global TFI IE > 




{ < UPLINK RELEASE : bit (1 ) > 




< DOWNLINK RELEASE : bit (1) > 




< TBF_RELEASE_CAUSE : bit (4) = 


{ 0000] 0010 }> 


< padding bits > 




I < Non-distribution part error : bit (*) = 


-- < no string > > } 


I < Address information part error : bit (*) 


= < no string > > } 


! < Distribution part error : bit (*) = < no string 


> > ; 



Table 11.2.26.2: PACKET TBF RELEASE information element details 



PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 
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Global TFI IE 

This information element contains the TFI of the mobile station's which uplink and/or downlink TBF to be released. 
This field is defined in sub-clause 12.10. 

Uplink_Release (1 bit field) 

Downlink_Release (1 bit field) 

These fields indicate which TBF shall be release, uplink or downlink. Both directions can be released at the same time. 

TBF shall not be released 

1 TBF shall be released 

TBF_RELEASE_CAUSE (4 bit field) 

This field indicates the reason for the release of the TBF. This field is encoded according to the following table: 

bit 

4321 

Normal release 

10 Abnormal release 

All other values are reserved, the same behaviour in reception as if 'Abnormal release'. 



11.2.27 (void) 

1 1 .2.28 Packet Uplink Ack/Nack 

This message is sent on the PACCH by the network to the mobile station indicate the status of the received RLC data 
blocks. This message may also update the timing advance and power control parameters. 

Message type: PACKET UPLINK ACK/NACK 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.28.1 : PACKET UPLINK ACK/NACK information elements 

< Packet Uplink Ack/Nack message content > ::= 
< PAGE MODE : bit (2) > 
{ 00 < UPLINK_TFI : bit (5) > 
{ -- Message escape 

{ < CHANNEL_CODING_COMMAND : bit (2) > 

< Ack/Nack Description : < Ack/Nack Description IE > > 
{ I 1 < CONTENTION_RESOLUTION_TLLI : bit (32) > } 
{ I 1 < Packet Timing Advance : < Packet Timing Advance IE > > } 
{ I 1 < Power Control Parameters : < Power Control Parameters IE > > } 
{0|1 < Extension Bits : Extension Bits IE > } -- sub-clause 12.26 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

{ null I bit** = < no string > - Receiver backward compatible with earlier version 
I 1 -- Additions for R99 

{ I 1 <Packet Extended Timing Advance : bit (2) >} 
<TBF_EST:bit(1)> 

{ null I bit** = <no string> -- Receiver backward compatible with earlier version 
I 1 -- Additions for REL-5 

{ I 1 < CONTENTION_RESOLUTION Identifier extension : bit (4) > } 
{ I 1 < RB Id : bit (5) > } 

< padding bits > } } 

! < Non-distribution part error : bit (*) = < no string > > } 
I 1 -- Message escape bit used to define EGPRS message contents 

{ 00 { < EGPRS Channel Coding Command : < EGPRS Modulation and Coding IE » 
<RESEGMENT:bit(1)> 

< PRE_EMPTIVE_TRANSMISSION : bit (1) > 

< PRR RETRANSMISSION REQUEST : bit (1) > 

< ARAC RETRANSMISSION REQUEST : bit (1) > 

{ I 1 < CONTENTION_RESOLUTION_TLLI : bit (32) > } 

<TBF_EST:bit(1)> 
{ I 1 < Packet Timing Advance : < Packet Timing Advance IE > > } 
{ I 1 < Packet Extended Timing Advance : bit (2) > } 
{ I 1 < Power Control Parameters : < Power Control Parameters IE > > } 
{0|1 < Extension Bits : Extension Bits IE > } -- sub-clause 12.26 

{ < EGPRS Ack/Nack Description : < EGPRS Ack/Nack Description IE > > 
-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

}// 

{ null I bit** = <no string> - Receiver backward compatible with earlier version 
I 1 -- Additions for REL-5 

{ I 1 < CONTENTION_RESOLUTION Identifier extension : bit (4) > } 

{ I 1 < RB Id : bit (5) > } 

< padding bits > } 

! < Non-distribution part error : bit (*) = < no string > > } 
! < IVIessage escape : {01 1 1 | 1 1 } bit (*) = <no string> > } } - Extended for future changes 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 



Table 11.2.28.2: PACKET UPLINK ACK/NACK information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

UPLINK_TFI (5 bit field) 

This field identifies the uplink TBF to which this message applies. This field is coded the same as the TFI field defined 

in sub-clause 12.15. On DBPSCH, this field equals the radio bearer identity of the radio bearer to which this message 

applies. 
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CHANNEL_CODING_COMMAND (2 bit field) 

The Channel Coding Indicator field indicates the channel coding scheme that the mobile station shall use when 

transmitting on the uplink. 



bits 




2 1 


value 


00 


CS-1 


01 


CS-2 


10 


CS-3 


1 1 


CS-4 



Ack/Nack Description 

This information element is defined in sub-clause 12.3. 

EGPRS Modulation and Coding Scheme 

The EGPRS Modulation and Coding Scheme information element is defined in sub-clause 12.10d. 

RESEGMENT (1 bit field) 

This field is defined in sub-clause 12.10e. 

PRE_EMPTIVE_TRANSMISSION (1 bit field) 

This bit informs the mobile station if it may or may not transmit the oldest RLC data block whose corresponding 
element in V(B) has the value PENDING_ACK (and repeating the process, refer to sub-clause 9.1.3.2) when the 
protocol is stalled or has no more RLC data blocks to transmit. 

The mobile station shall not use pre-emptive transmission. 

1 The mobile station shall use pre-emptive transmission. 

PRR RETRANSMISSION REQUEST (1 bit field) 

indicates that retransmission of a PACKET RESOURCE REQUEST message is not requested 

1 indicates that retransmission of a PACKET RESOURCE REQUEST message is requested 

ARAC RETRANSMISSION REQUEST (1 bit field) 

indicates that retransmission of an ADDITIONAL MS RADIO ACCESS CAPABILITIES message is not requested 

1 indicates that retransmission of an ADDITIONAL MS RADIO ACCESS CAPABILITIES message is requested 

EGPRS Ack/Nack Description 

This information element is defined in sub-clause 12.3.1. The number of bits (L) available for Ack/Nack Description 
information element depends on the inclusion of other information elements. L may be set so that the entire 
PACKET UPLINK ACK/NACK message evenly fits into an RLC/MAC control block. If a lower L covers the entire 
receive window, that L may be used. 

CONTENTION_RESOLUTION_TLLI (32 bit field) 

The CONTENTION_RESOLUTION_TLLI field is present only if the network has decoded one of the uplink RLC data 

blocks containing the TLLI or G-RNTI. The mobile station shall perform the contention resolution function if the TLLI 

or G-RNTI information element is present. This field contains a TLLI or a G-RNTI, which is defined in sub-clause 

12.16. 

Packet Timing Advance 

This information element is defined in sub-clause 12.12. 

Power Control Parameters 

This information element, if present, contains power control command for the mobile station. If this information 
element is not present for certain previously allocated timeslots, the MS shall continue to use the previous power on 
these timeslots. This information element is defined in sub-clause 12.13. 

Extension Bits 

This information element, if present, shall be skipped over. Any information content shall be ignored by the mobile 
station. This information element is defined in sub-clause 12.26. 
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TBF Starting Time 

The TBF Starting Time field contains a starting time that indicates the earliest frame number during which the assigned 
TBF may start. 

The MS shall continue to use the parameters of the existing TBF until the TDMA frame number occurs. When the 
indicated TDMA frame number occurs, the mobile station shall immediately begin to monitor the USF field and use the 
new assigned uplink TBF parameters when its USF has occurred. 

This information element is defined in sub-clause 12.21. 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 

TBF_EST(1 bit field) 

If included, this field indicates that the mobile station is allowed to request the establishment of new TBF on PACCH. 

the mobile station is not allowed to request the establishment of new TBF 

1 the mobile station is allowed to request the establishment of new TBF 

CONTENTION_RESOLUTION Identifier extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the CONTENTION_RESOLUTION_TLLI field 
which are necessary to provide a unique identifier for contention resolution in lu-mode. This field is present when an 
assigned G-RNTI is used during the contention resolution procedure. 

RB Id (5 bit field) 

This field contains the radio bearer identity of the mobile station's radio bearer for which the uplink data transfer on 
SFACCH is acknowledged. This field is not included when the PACKET UPLINK ACK/NACK messsage is sent on 
DBPSCH. This field is encoded as a binary number with range 0-3 1 . 



1 1 .2.28a Packet DBPSCH Uplink Ack/Nack 



This message is sent on FACCH, SACCH or SDCCH from the network to the mobile station to indicate the status of 
uplink RLC data blocks received. 

Message type: PACKET DBPSCH UPLINK ACK/NACK 

Direction: network to mobile station 

Classification: DBPSCH message 

Table 11. 2.28a.1: PACKET DBPSCH UPLINK ACK/NACK information elements 

< Packet DBPSCH Uplink Ack/Nack message content > ::= 
{ < MESSAGE_TYPE : bit (6) == 001001 > 
< RB Id : bit (5) > 
{ I 1 < CONTENTION_RESOLUTION_TLLI : bit (32) > 

{ I 1 < G-RNTI extension : bit (4) > } } 
{0 -TCH TBF mode 

{0 -All data blocks acknowledged, no retransmission requested 
I 1 < STARTING_SEQUENCE_NUMBER : bit (8) > 

< RECEIVED_BLOCK_BITMAP : bit (128) > } 
I 1 -DCCH TBF mode 

{0 -All data blocks acknowledged, no retransmission requested 
I 1 < STARTING_SEQUENCE_NUMBER : bit (4) > 

< RECEIVED_BLOCK_BITMAP : bit (8) > } } 
<padding bits > 

! < DBPSCH message part error : bit (*) = < no string > > } ; 
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Table 11.2.28a.2: PACKET DBPSCH UPLINK ACK/NACK information element details 

CONTENTION_RESOLUTION_TLLI (32 bit field) 

The CONTENTION_RESOLUTION_TLLI field is present only if the network has decoded one of the uplink RLC data 
blocks containing the G-RNTI. The mobile station shall perform the contention resolution function if the G-RNTI 
information element is present. This field contains a G-RNTI, which is defined in sub-clause 12.16. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the CONTENTION_RESOLUTION_TLLI field 
which are necessary to provide a unique identifier for contention resolution in lu-mode. This field is present when an 
assigned G-RNTI is used during the contention resolution procedure. 

RB Id (5 bit field) 

This field contains the radio bearer identity of the mobile station's radio bearer for which the uplink data transfer is 

acknowledged. This field is encoded as a binary number with range 0-3 1 . 

STARTING_SEQUENCE_NUMBER (8 or 4 bit field) 

The SSN contains the value of V(R) when this information element was transmitted. This field is encoded as the binary 

representation of V(R). 

Range to 255 (8 bit field) 

Range to 15 (4 bit field) 

RECEIVE_BLOCK_BITMAP (RBB) (128 or 8 bit field) 

The RBB is a bitmap representing Block Sequence Numbers. The bitmap is indexed relative to SSN as follows: 

BSN = (SSN - bit_number) modulo 256, for bit_number = 1 to 128 128 bit field). 
BSN = (SSN - bit_number) modulo 16, for bit_number = 1 to 8 (8 bit field). 

The BSN values represented range: 

fi-om (SSN - 1) mod 256 to (SSN - 128) mod 256 (128 bit field) 
fi-om (SSN - 1) mod 16 to (SSN - 8) mod 16 (8 bit field) 

The value of each bit represents the acknowledgement status of the RLC data block with: 

BSN = (SSN - bit_number) mod 256 (128 bit field) 
BSN = (SSN - bit_number) mod 16 (8 bit field), 

it is encoded as follows: 

Negative acknowledgement 

1 Positive acknowledgement 

Mapping of the bitmap is defined in 3GPP TS 44.160. 



1 1 .2.28b Packet DBPSCH Uplink Ack/Nack Type 2 

This message shall only be used when FLO is used. It is sent on ADCH from the network to the mobile station to 
indicate the status of uplink RLC data blocks received. 

Message type: PACKET DBPSCH UPLINK ACK/NACK TYPE 2 

Direction: network to mobile station 

Classification: DBPSCH message 
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Table 11. 2.28b.1 : PACKET DBPSCH UPLINK ACK/NACK TYPE 2information elements 

< Packet DBPSCH Uplink Ack/Nack message content > ::= 

{ < MESSAGE_TYPE : bit (6) == 001 001 > -- The same message type as for Packet DBPSCH Uplink Ack/Nack is 

-- used since tliese two messages are mutualiy exclusive. 
< RB Id : bit (5) > 
{0 - UDCH TBF mode 

{ -- All data blocks acknowledged, no retransmission requested 
I 1 < FLO Ack/Nack Description : < FLO Ack/Nack Description IE > > } 
I 1 -CDCH TBF mode 

{ -- Ail data blocks acknowledged, no retransmission requested 
I 1 < STARTING_SEQUENCE_NUMBER : bit (4) > 
< RECEIVED_BLOCK_BITMAP : bit (8) > } } 
<padding bits > 
! < DBPSCH message part error : bit (*) = < no string > > } ; 

Table 11.2.28b.2: PACKET DBPSCH UPLINK ACK/NACK TYP2 2 information element details 

RB Id (5 bit field) 

This field contains the radio bearer identity of the mobile station's radio bearer for which the uplink data transfer is 

acknowledged. This field is encoded as a binary number with range 0-3 1 . 

STARTING_SEQUENCE_NUMBER (4 bit field) 

The SSN contains the value of V(R) when this information element was transmitted. This field is encoded as the binary 
representation of V(R). 
Range to 15 (4 bit field) 

RECEIVE_BLOCK_BITMAP (RBB) (128 or 8 bit field) 

The RBB is a bitmap representing Block Sequence Numbers. The bitmap is indexed relative to SSN as follows: 

BSN = (SSN - bit_number) modulo 16, for bit_number = 1 to 8 (8 bit field). 
The BSN values represented range: 

from (SSN - 1) mod 16 to (SSN - 8) mod 16 (8 bit field) 
The value of each bit represents the acknowledgement status of the RLC data block with: 

BSN = (SSN - bit_number) mod 16 (8 bit field), 
it is encoded as follows: 

Negative acknowledgement 

1 Positive acknowledgement 

Mapping of the bitmap is defined in 3GPP TS 44.160. 



1 1 .2.29 Packet Uplink Assignment 



This message is sent on the PCCCH or PACCH by the network to the mobile station to assign uplink resources. The 
mobile station may be addressed by TFI, TQI, or Packet Request Reference depending upon the procedure used. A 
mobile allocation or reference frequency list received as part of this assignment message shall be valid until new 
assignment is received or each TBF of the MS are terminated. 

Message type: PACKET UPLINK ASSIGNMENT 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.29.1: PACKET UPLINK ASSIGNMENT information elements 

< Packet Uplink Assignment message content > ::= 
< PAGE_MODE : bit (2) > 
{ I 1 <PERSISTENCE_LEVEL : bit (4) > * 4 } 
{ {0 <GlobalTFI :<GlobalTFI IE>> 
I 10 < ILL! / G-RNTI : bit (32) > 
I 110 <TQI :bit(16)> 

j 1 11 < Packet Request Reference : < Packet Request Reference IE > > } 
{ -- Message escape 

{ < CHANNEL_CODING_COMMAND : bit (2) > 

< TLLI_BLOCK_CHANNEL_CODING : bit (1) > 

< Packet Timing Advance : < Packet Timing Advance IE > > 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

{ 01 < Dynamic Allocation : < Dynamic Allocation struct > > 

I 1 < Single Block Allocation : < Single Block Allocation struct > > 

I 00 < extension > } -- The value '1 1 ' was allocated in an earlier version of the protocol 

-- and shall not be used. 
{ null I bit** = < no string > -- Receiver backward compatible with earlier version 
I 1 -- Additions for R99 

{ I 1 < Packet Extended Timing Advance : bit (2) > } 

{ null I bit** = <no string> -- Receiver backward compatible with earlier version 
I 1 -- Additions for REL-5 

{ I 1 < G-RNTI extension : bit (4) > } 
{ I 1 < RB Id : bit (5) > } 

{ null I bit** = <no string> -- Receiver backward compatible with earlier version 
I 1 -- Additions for REL-6 

{ I 1 < PFI : bit (7) > } 
{0| 1 <RLC_M0DE:bit(1)>} 

< padding bits > } } } 

! < Non-distribution part error : bit (*) = < no string > > } 
I 1 -- Message escape bit used to define EGPRS message contents 
{ 00 { { I 1 <CONTENTION_RESOLUTION_TLLI : bit(32) > } 

{ I 1 < COMPACT reduced MA : < COMPACT reduced MA IE » } 

< EGPRS Channel Coding Command : < EGPRS Modulation and Coding IE » 
<RESEGMENT:bit(1)> 

< EGPRS Window Size : < EGPRS Window Size IE > > 

{ I 1 < Access Technologies Request : Access Technologies Request struct >} 

< ARAC RETRANSMISSION REQUEST : bit (1) > 

< TLLI_BLOCK_CHANNEL_CODING : bit (1) > 

{ I 1 < BEP_PERI0D2 : bit (4) > } 

< Packet Timing Advance : < Packet Timing Advance IE > > 
{ I 1 < Packet Extended Timing Advance : bit (2) > } 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

{ 01 < Dynamic Allocation : < Dynamic Allocation struct > > 

I 1 < Multi Block Allocation : < Multi Block Allocation struct > > 

I 00 < extension > } -- The value '1 1 ' was allocated in an earlier version of the protocol 

-- and shall not be used. 
{ null I bit** = <no string> - Receiver backward compatible with earlier version 
I 1 -- Additions for REL-5 

{ I 1 < G-RNTI extension : bit (4) > } 
{ I 1 < RB Id : bit (5) > } 

{ null I bit** = <no string> -- Receiver backward compatible with earlier version 
I 1 -- Additions for REL-6 

{ I 1 < PFI : bit (7) > } 
{0| 1 <RLC_M0DE:bit(1)>} 

< padding bits > } } 

! < Non-distribution part error : bit {*) = < no string > > } 
! < Message escape : { 01 1 1 | 1 1 } bit {*) = <no string> > }} - Extended for future changes 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

<extension> ::= - Future extension can be done by modifying this structure 
null ; 
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<Dynamic Allocation struct > ::= 

< EXTENDED_DYNAMIC_ALLOCATION : bit (1) > 
{ I 1 < PO : bit (4) > 

<PR_M0DE:bit(1)>} 

< USF_GRANULARITY : bit (1) > 

{ I 1 < UPLINK_TFI_ASSIGNMENT : bit (5) > } 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. { | 1 

< TBF Starting Time : < Starting Frame Number Description IE > > } 

{ -- Timeslot Allocation 

{ I 1 < USF_TNO : bit (3) > } 
{ I 1 < USF_TN1 : bit (3) > } 
{ I 1 < USF_TN2 : bit (3) > } 
{ I 1 < USF_TN3 : bit (3) > } 
{ I 1 < USF_TN4 : bit (3) > } 
{ I 1 < USF_TN5 : bit (3) > } 
{ |1 < USF_TN6 : bit (3) > } 
{ I 1 < USF_TN7 : bit (3) > } 

1 1 - Timeslot Allocation with Power Control Parameters 

< ALPHA : bit (4) > 

{ I 1 < USF_TNO : bit (3) > 

< GAI\/IMA_TNO : bit (5) > } 
{ I 1 < USF_TN1 : bit (3) > 

< GAI\/IMA_TN1 : bit (5) > } 
{ I 1 < USF_TN2 : bit (3) > 

< GAI\/IMA_TN2 : bit (5) > } 
{ |1 < USF_TN3 : bit (3) > 

< GAI\/IMA_TN3 : bit (5) > } 
{ I 1 < USF_TN4 : bit (3) > 

< GAI\/IMA_TN4 : bit (5) > } 
{ I 1 < USF_TN5 : bit (3) > 

< GAI\/IMA_TN5 : bit (5) > } 
{ I 1 < USF_TN6 : bit (3) > 

< GAI\/IMA_TN6 : bit (5) > } 
{ I 1 < USF_TN7 : bit (3) > 

< GAI\/IMA_TN7 : bit (5) > } } ; 

<Single Block Allocation struct > ::= 

< TIMESLOT_NUMBER : bit (3) > 
{ I 1 < ALPHA : bit (4) > 

< GAMI\/IA_TN : bit (5) >} 

{ I 1 < PO : bit (4) > 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

<PR_M0DE:bit(1)>} 

< TBF Starting Time : < Starting Frame Number Description IE > > ; 

< Multi Block Allocation struct > ::= 

< TIMESLOT_NUMBER : bit (3) > 
{ I 1 < ALPHA : bit (4) > 

< GAMI\/IA_TN : bit (5) >} 
{ I 1 < PO : bit (4) > 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

<PR_M0DE:bit(1)>} 

< TBF Starting Time : < Starting Frame Number Description IE > > 

< NUIVIBER OF RADIO BLOCKS ALLOCATED: bit (2)>; 

<Access Technologies Request struct> ::= -- recursive structure allows any combination of Access technologies 
<Access Technology Type : bit {4)> 
{ I 1 <Access Technologies Request struct> }; 



Table 11.2.29.2: PACKET UPLINK ASSIGNMENT information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 
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PERSISTENCE_LEVEL (4 bit field for each Radio Priority 1 . . .4) 
This field is defined in sub-clause 12.14, PRACH Control Parameters. 

Global TFI 

This information element identifies the uplink TFI, if available, or the downlink TFI, to which this message applies. 
This field is defined in sub-clause 12.10. 

TLLI / G-RNTI 

This information element is defined in sub-clause 12.16. 

TQI (16 bit field) 

This field is defined in sub-clause 12.17. 

Packet Request Reference 

This information element is defined in sub-clause 12.1 1. 

CHANNEL_CODING_COMMAND (2 bit field) 

The Channel Coding Indicator field indicates the channel coding scheme that the mobile station shall use when 

transmitting data on the uplink. 



bit 




21 




00 


CS-1 


1 


CS-2 


1 


CS-3 


1 1 


CS-4 



CONTENTION_RESOLUTION_TLLI (32 bit field) 

The CONTENTION_RESOLUTION_TLLI field is present only if the network has decoded one of the upHnk blocks 
containing the TLLI or G-RNTI during the EGPRS one phase access. The mobile station shall perform the contention 
resolution function if this field is present. This field contains a TLLI or G-RNTI, which is defined in sub-clause 12.16. 
See sub-clause 7.1.2.3a. 

COMPACT reduced MA 

This information element is defined in sub-clause 12.29. 

EGPRS Modulation and Coding Scheme 

The EGPRS Modulation and Coding Scheme information element is defined in sub-clause 12.10d. 

RESEGMENT (1 bit field) 

This field is defined in sub-clause 12.10e. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

TLLI_BLOCK_CHANNEL_CODING (1 bit field) 

This field indicates the channel coding command that the mobile station shall use for any RLC data block containing a 

TLLI field in the RLC data block header. This field is coded as shown: 

the mobile station shall use CS-1 in GPRS TBF mode and MCS-1 in EGPRS TBF mode. 

1 the mobile station shall use the value commanded in the CHANNEL_CODING_COMMAND or 
EGPRS_CHANNEL_CODING_COMMAND field. 

BEP_PERIOD2 (4 bit field) 

This field contains a constant which is used for filtering channel quality measurements in EGPRS. BEP_PERIOD2 

when present, or if not, when received in a previous message of the same TBF session, shall be used instead of 

BEP_PERIOD. For details see 3GPP TS 45.008. 

Range: to 15 

UPLINK_TFI_ASSIGNMENT (5 bit field) 

This information element, if present, assigns the contained TFI to the mobile station to identify to uplink TBF described 

by this message. This field is coded the same as the TFI field defined in sub-clause 12.15. 
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Packet Timing Advance 

This information element is defined in sub-clause 12.12. 

Frequency Parameters 

This information element, if present, assigns frequency parameters to the uplink TBF. If this information element is not 
present the mobile station shall use its previously assigned frequency parameters. This information element is defined in 

sub-clause 12.8. 

Dynamic Allocation struct 

This information element contains parameters necessary to define the radio resources of a dynamic allocation or an 
extended dynamic allocation. 

EXTENDED_DYNAMIC_ALLOCATION (1 bit field) 

This information field indicates the medium access mode to be used during the TBF. 

Dynamic Allocation 

1 Extended Dynamic Allocation 

Power Control Parameters 

This information element, if present, contains power control parameters and the timeslot allocation for the mobile 
station. If this information element is not present, the MS shall continue to use the previous parameters. This 
information element is defined in sub-clause 12.13. 

TBF Starting Time 

The TBF Starting Time field contains a starting time that indicates the frame number during which the assigned TBF 

may start. 

In case of dynamic allocation, if no uplink TBF is in progress, the MS need not monitor the USF field until the TDMA 
frame number occurs. When the indicated TDMA frame number occurs, the mobile station shall immediately begin to 
monitor the USF field and use the new assigned uplink TBF parameters when its USF has occurred. If an uplink TBF is 
already in progress, the MS shall continue to use the parameters of the existing TBF until the TDMA frame number 
occurs. When the indicated TDMA frame number occurs, the mobile station shall immediately begin to monitor the 
USF field and use the new assigned uplink TBF parameters when its USF has occurred. 

In case of single block allocation, the mobile station shall use the assigned timeslot during the RLC/MAC block whose 
first TDMA burst occurs in the indicated TDMA frame number. 

This information element is encoded as the Starting Frame Number Description IE. See sub-clause 12.21. 

USF for Timeslot Number (TNO) (3 bit field) 
USF for Timeslot Number 1 (TNI) (3 bit field) 
USF for Timeslot Number 2 (TN2) (3 bit field) 
USF for Timeslot Number 3 (TN3) (3 bit field) 
USF for Timeslot Number 4 (TN4) (3 bit field) 
USF for Timeslot Number 5 (TN5) (3 bit field) 
USF for Timeslot Number 6 (TN6) (3 bit field) 
USF for Timeslot Number 7 (TN7) (3 bit field) 

These fields indicate the USF value assigned to the MS for allocated timeslots (range to 7). These fields are encoded 
as a binary presentation of the USF value as defined in sub-clause 10.4.1. 

USF_GRANULARITY (1 bit field) 

This information field indicates the USF granularity to be applied by the mobile station when it is assigned a TBF using 

Dynamic Allocation or Extended Dynamic Allocation. 

the mobile station shall transmit one RLC/MAC block 

1 the mobile station shall transmit four consecutive RLC/MAC blocks 

Single Block Allocation struct 

This information element contains parameters necessary to define the radio resources of a Single Block allocation. For 
example for sending of a PACKET RESOURCE REQUEST message in a two phase access or a Measurement report. 
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TIMESLOT_NUMBER (3 bit field) 

This field indicates the timeslot assigned for transfer of a single RLC/MAC block on the uplink. This field is coded as 

the binary representation of the timeslot number as defined in 3GPP TS 45.010. 

Range to 7 

ALPHA (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 

GAMMA_TN (5 bit field) 

The GAMMA_TN field is the binary representation of the parameter FCH for MS output power control in units of 2 

dB, see 3GPP TS 45.008. The GAMMA_TN field is coded according to the following table: 

bit 

5432 1 

rCH = dB 

1 rCH = 2 dB 

11110 rCH = 60 dB 

11111 rCH = 62 dB 

PO (4 bit field) 

This field is an optional downlink power control parameter. If PO is present, then downlink power control is used; 

otherwise, if PO is not present, then downlink power control is not used. It is encoded as follows: 



bit 




4321 




0000 


PO = dB 


0001 


PO = 2 dB 


0010 


PO = 4 dB 


1111 


PO = 30 dB 



PR_MODE(l bit field) 

This field indicates, as defined in 3GPP TS 45.008. It is encoded as follows: 

PR mode A: for one addressed MS 

1 PR mode B: for all MS 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 

Multi Block Allocation struct 

This information element contains parameters necessary to define the radio resources of a Multi Block allocation. 

NUMBER OF RADIO BLOCKS ALLOCATED (2 bit field) 

Bits 

10 

1 radio block reserved for uplink transmission 

1 2 radio blocks reserved for uplink transmission 

1 reserved for future use 
1 1 reserved for future use 

ACCESS TECHNOLOGY TYPE 

This field indicates the access technology that is requested from the mobile station. The field is coded according to the 

definition in 3GPP TS 24.008. The access technology types requested from the MS in the Access Technologies Request 

structure shall be classified by priority, the most important first. The MS shall reply using the same order. 

Among the three GSM 900 access technology types GSM P, GSM E and GSM R only one shall be requested by the 

network. 

ARAC RETRANSMISSION REQUEST (1 bit field) 

indicates that retransmission of an ADDITIONAL MS RADIO ACCESS CAPABILITIES message is not requested 

1 indicates that retransmission of an ADDITIONAL MS RADIO ACCESS CAPABILITIES message is requested 
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G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field which are necessary to 
provide a unique identifier for contention resolution in lu-mode. This field may also be included when an assigned G- 
RNTI is used in the CONTENTION_RESOLUTION_TLLI field during the contention resolution procedure. 

RB Id (5 bit field) 

This field is included in lu mode when a TBF is assigned in MAC-Shared state. It contains the radio bearer identifier for 
the radio bearer using the assigned TBF. 

PFI (7 bit field) 

This field contains the PFI parameter identifying the Packet Flow Context related to the TBF identified in the 
UPLINK_TFI_ASSIGMENT field. The PFI parameter is encoded as the contents of the PFI information element 
defined in 3GPP TS 44.018. 



RLC_MODE(l bit field) 

This field contains the RLC mode to be used for the assigned TBF. 

RLC acknowledged mode 

1 RLC unacknowledged mode 



1 1 .2.29.1 Special requirements in dual transfer mode for uplink TBF 

Special requirements apply when an uplink TBF is assigned to a mobile station in dual transfer mode or about to enter 
dual transfer mode. 

If the mobile station has an RR connection to the network on a half-rate TCH, the network may assign an uplink TBF 
using the other sub-channel of the same timeslot for a half -rate PDCH (see 3GPP TS 45.002). In this case, the uplink 
assignment message shall be encoded with a timeslot allocation including the timeslot number for the half-rate TCH and 
the half-rate PDCH, and only that timeslot number. The mobile station shall interpret this allocation as an allocation of a 
half-rate PDCH. 

In dual transfer mode, the mobile station may be assigned an uplink TBF using exclusive allocation. The exclusive 
allocation shall be applied according to the conditions specified in sub-clause 8.1.0. When the exclusive allocation is 
applied, the mobile station shall ignore the USF values assigned in the uplink assignment message. 

1 1 .2.29a Multiple TBF Uplink Assignment 

This message is sent on the PACCH by the network to the mobile station to assign uplink resources. The mobile station 
may be addressed by the G-RNTI or the TFI depending upon the procedure used. A mobile allocation or reference 
frequency list received as part of this assignment message shall be valid until new assignment is received or each TBF 
of the MS are terminated. 

Message type: MULTIPLE TBF UPLINK ASSIGNMENT 

Direction: network to mobile station 

Classification : non-distribution message 
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Table 11. 2.29a.1: MULTIPLE TBF UPLINK ASSIGNMENT information elements 

< Multiple TBF Uplink Assignment message content > ::= 
< PAGE_MODE : bit (2) > 
{ I 1 < PERSISTENCE_LEVEL : bit (4) > * 4 } 
{ {0 <GlobalTFI :<GlobalTFI IE>> 

I 10 { < TLLI / G-RNTI : <TLLI / G-RNTI IE > >< G-RNTI extension : bit (4) > } } 
{ -- Message escape bit for GPRS mode TBFs 

{ { I 1 < CHANNEL_CODING_COIVIMAND : bit (2) > } 

< TLLI_BLOCK_CHANNEL_CODING : bit (1) > 

< Pacl<et Timing Advance : < Packet Timing Advance IE > > 
{ I 1 < Packet Extended Timing Advance : bit (2) > } 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 
{ I 1 < Uplink TBF Assignment : < Uplink Assignment struct > > } 

< padding bits > } 

! < Non-distribution part error : bit (*) = < no string > > } 
I 1 -- Message escape bit for EGPRS mode TBFs 
{00 

{ {0|1 < EGPRS WindowSize:< EGPRS WindowSize IE >>} 

{ I 1 < EGPRS Channel Coding Command : < EGPRS Modulation and Coding IE > > } 

< Resegment : < RESEGMENT IE » 

< TLLI_BLOCK_CHANNEL_CODING : bit (1) > 
{ I 1 < BEP_PERI0D2 : bit(4) > } 

< Packet Timing Advance : < Packet Timing Advance IE > > 
{ I 1 < Packet Extended Timing Advance : bit (2) > } 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 
{ I 1 < Uplink TBF Assignment : < Uplink Assignment struct > > } 

< padding bits > } 

! < Non-distribution part error : bit {*) = < no string > > } 
! < Message escape : { 01 1 1 | 1 1 } bit (*) = < no string > > } } - Extended for future ctianges 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 



< Uplink Assignment struct > : 
< EXTENDED DYNAIMIC 



ALLOCATION :bit(1) 



{ I 1 < Uplink Control Timeslot : bit (3) > } 

{ I 1 < PO : bit (4) > 

<PR_M0DE:bit(1)>} 
{ I 1 < TBF Starting Time : < Starting Frame Number Description IE > > } 
{ I 1 < Global Timeslot description : < Timeslot description struct > > 

{ 1 < Uplink TBF Assignment : < Uplink TBF Assignment struct > > } ** } 



< Timeslot description struct > ::= 
{0 

< MS TIMESLOT ALLOCATION 



1 



ALPHA : bit (4) 



{0 
{0 
{0 
{0 
{0 
{0 
{0 
{0 



< GAMMA_TNO : 

< GAMMA_TN1 : 

< GAMMA_TN2 : 

< GAMMA_TN3 : 

< GAMMA_TN4 : 

< GAMMA_TN5 : 

< GAMMA_TN6 : 

< GAMMA TN7 : 



bit (8) > 



- without power cor)troi params 
witti power controi params 



bit (5) > } 
bit (5) > } 
bit (5) > } 
bit (5) > } 
bit (5) > } 
bit (5) > } 
bit (5) > } 
bit (5) > } } 
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< Uplink TBF Assignment struct > ::= - Recursive for multiple TBFs 

{ < RB Id : bit (5) > 
I 1 < PFI : bit (7) > } 

<RLC_M0DE:bit(1)>} 

< TFI Assignment : bit (5) > 

{ I 1 < CHANNEL_CODING_COMMAND : bit (2) > } 

{ I 1 < EGPRS Channel Coding Command : < EGPRS Modulation and Coding Scheme IE > > } 

{ I 1 < EGPRS Window Size : < EGPRS Window Size IE > > } 

< USF_GRANULARITY : bit (1) > 

{ -- The timeslots assigned to the TBF are all the timeslots assigned 

- in the Global Timeslot description 
I 1 < TBF_TIMESLOT_ALLOCATION : bit (N) > } -- The timeslots assigned to the TBF are a subset of all the 

-- timeslots assigned in the Global Timeslot description. Where 

- N is the amount of timeslots assigned to the IVIS in the Global 

- Timeslot description 

{ < USF_ALLOCATION : bit (3) > - The same USF is valid on all timeslots assigned to the TBF 

I 1 -- Different USF(s) assigned 

< USF_ALLOCATION : bit (3) > -- USF assignment on the lowest numbered timeslot 

-- assigned to the TBF 
{ I 1 < USF_ALLOCATION : bit (3) > } * (M-1 ) } ; -- USFs on subsequent timeslots assigned to the TBF: 

-A '0' (respectively a '1 ' followed by a USF value) 
-- means same (respectively different) USF value as the 
-- USF on the next lower numbered timeslot assigned to 
-- the TBF. Where M is the amount of timeslots assigned 
- to the TBF in the TBF_TIMESLOT_ALLOCATION if 
-- present, else in the Global Timeslot description 



Table 11.2.29a.2: MULTIPLE TBF UPLINK ASSIGNMENT information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

PERSISTENCE_LEVEL (4 bit field for each Radio Priority 1 . . .4) 
This field is defined in sub-clause 12.14, PRACH Control Parameters. 

TLLI / G-RNTI 

This information element is defined in sub-clause 12.16. 

G-RNTI extension (4 bit field) 

This field contains the extra 4 bits of the G-RNTI not included in the TLLI / G-RNTI field or 
CONTENTION_RESOLUTION Identifier field which are necessary to provide a unique identifier for contention 
resolution in lu-mode. 

Global TFI 

This information element identifies one of the mobile station's downlink or uplink TFIs. This field is defined in sub- 
clause 12.10. 

CHANNEL_CODING_COMMAND (2 bit field) 

The Channel Coding Indicator field indicates the channel coding scheme that the mobile station shall use when 
transmitting data on the uplink. If this field is included in the main body of the message, it shall refer to all GPRS TBF 
mode uplink TBFs assigned in the message (default value). If this field is included in the Uplink TBF Assignment 
struct, it refers only to the TBF given by the TFI Assignment (this specific value overrules the default value). Every 
TBF defined in GPRS TBF mode shall be assigned either the default value or a specific value. 



Bit 




21 




00 


CS-1 


01 


CS-2 


10 


CS-3 


1 1 


CS-4 
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RESEGMENT (1 bit field) 

This field is defined in sub-clause 12.10e. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

If this field is included in the main body of the message, it shall refer to all EGPRS TBF mode uplink TBFs assigned in 
the message (default value). If this field is included in the Uplink TBF Assignment struct, it refers only to the TBF 
given by the TFI Assignment (this specific value overrules the default value). Every TBF defined in EGPRS TBF mode 
shall be assigned either the default value or a specific value. 

EGPRS Modulation and Coding Scheme 

This field contains the EGPRS Modulation and Coding Scheme information element defined in sub-clause 12.10d. 

If this field is included in the main body of the message, it shall refer to all EGPRS TBF mode uplink TBFs assigned in 
the message (default value). If this field is included in the Uplink TBF Assignment struct, it refers only to the TBF 
given by the TFI Assignment (this specific value overrules the default value). Every TBF defined in EGPRS TBF mode 
shall be assigned either the default value or a specific value. 

TLLI_BLOCK_CHANNEL_CODING (1 bit field) 

This field indicates the channel coding command that the mobile station shall use for any RLC data block containing a 

TLLI / G-RNTI field in the RLC data block header. This field is coded as shown: 

the mobile station shall use CS-1 in GPRS TBF mode and MCS-1 in EGPRS TBF mode. 

1 the mobile station shall use the value commanded in the CHANNEL_CODING_COMMAND or 
EGPRS_CHANNEL_CODING_COMMAND field. 

BEP_PERIOD2 (4 bit field) 

This field contains a constant which is used for filtering channel quality measurements in EGPRS. BEP_PERIOD2 

when present, or if not, when received in a previous message of the same TBF session, shall be used instead of 

BEP_PERIOD. For details see 3GPP TS 45.008. 

Range: to 15 

TFI Assignment (5 bit field) 

This information element assigns one TFI to each TBF assigned to the mobile station in this message. This field is 

repeated for each TBF that is assigned in this message. TFI values are encoded as defined in sub-clause 12.15. 

RB Id (5 bit field) 

This field contains the radio bearer identifier for the radio bearer using the assigned TBF. This provides the mapping of 

TFI to RB Id which is necessary to uniquely identify lu-mode data flows. 

PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context. The PFI parameter is encoded as the contents 
of the PFI information element as defined in 3GPP TS 44.018. 

RLC_MODE(l bit field) 

This field contains the RLC mode to be used for the assigned TBF. 

RLC acknowledged mode 

1 RLC unacknowledged mode 

Uplink Control Timeslot (3 bit field) 

This field contains the timeslot number of the timeslot where the PACCH for the MS is located. It is encoded as the 

binary representation of the timeslot number as defined in 3GPP TS 45.002. 

Packet Timing Advance 

This information element is defined in sub-clause 12.12. 

Frequency Parameters 

This information element, if present, assigns frequency parameters to the uplink TBF. If this information element is not 
present the mobile station shall use its previously assigned frequency parameters. This information element is defined in 
sub-clause 12.8. 
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EXTENDED_DYNAMIC_ALLOCATION (1 bit field) 

This information field indicates the medium access mode to be used during the TBF. 

Dynamic Allocation 

1 Extended Dynamic Allocation 

Power Control Parameters 

This information element, if present, contains power control parameters and the timeslot allocation for the mobile 
station. If this information element is not present, the MS shall continue to use the previous parameters. This 
information element is defined in sub-clause 12.13. 

TBF Starting Time 

The TBF Starting Time field contains a starting time that indicates the frame number during which the assigned TBF 
may start. 

In case of dynamic allocation, if no uplink TBF is in progress, the MS need not monitor the USF field until the TDMA 
frame number occurs. When the indicated TDMA frame number occurs, the mobile station shall immediately begin to 
monitor the USF field and use the new assigned uplink TBF parameters when its USF has occurred. If an uplink TBF is 
already in progress, the MS shall continue to use the parameters of the existing TBF until the TDMA frame number 
occurs. When the indicated TDMA frame number occurs, the mobile station shall immediately begin to monitor the 
USF field and use the new assigned uplink TBF parameters when its USF has occurred. 

In case of single block allocation, the mobile station shall use the assigned timeslot during the RLC/MAC block whose 
first TDMA burst occurs in the indicated TDMA frame number. 

This information element is encoded as the Starting Frame Number Description IE. See sub-clause 12.21. 

MS_TIMESLOT_ALLOCATION (8 bit field) 

This information field indicates the timeslots assigned for use by the MS for the assigned uplink TBFs. Bit 8 indicates 

the status of timeslot 0, bit 7 indicates the status of timeslot 1, etc. At least one timeslot must be assigned. 

Timeslot is not assigned 

1 Timeslot is assigned 

TBF_TIMESLOT_ALLOCATION (N bit field) 

This information field indicates the timeslots assigned to a particular uplink TBF, within the timeslots assigned to the 
MS in the Global Timeslot description. This field contains as many bits as there are timeslots assigned to the MS in the 
Global Timeslot description. Bit N indicates the status of the lowest numbered timeslot in the timeslots assigned to the 
MS in the Global Timeslot description. Bit N-1 (if any) indicates the status of the next lowest numbered timeslot, etc. 
At least one timeslot must be assigned per TBF 

Timeslot is not assigned 

1 Timeslot is assigned 

USF_ALLOCATION (3 bit field) 

This field indicates the USF value assigned to the MS for one or more allocated timeslots. This field is encoded as a 
binary presentation of the USF value as defined in sub-clause 10.4.1. 

USF_GRANULARITY (1 bit field) 

This information field indicates the USF granularity to be applied by the mobile station when it is assigned a TBF using 

Dynamic Allocation or Extended Dynamic Allocation. 

the mobile station shall transmit one RLC/MAC block 

1 the mobile station shall transmit four consecutive RLC/MAC blocks 

ALPHA (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 326 ETSI TS 144 060 V6.28.0 (2010-03) 

GAMMA_TN (5 bit field) 

The GAMMA_TN field is the binary representation of the parameter FCH for MS output power control in units of 2 

dB, see 3GPP TS 45.008. The GAMMA_TN field is coded according to the following table: 

bit 

5432 1 

rCH = dB 

1 rCH = 2 dB 

11110 rCH = 60 dB 

11111 rCH = 62 dB 

PO (4 bit field) 

This field is an optional downlink power control parameter. If PO is present, then downlink power control is used; 

otherwise, if PO is not present, then downlink power control is not used. It is encoded as follows: 

bit 

4321 

PO = dB 

1 PO = 2 dB 

10 PO = 4 dB 

1111 PO = 30 dB 

PR_MODE(l bit field) 

This field indicates, as defined in 3GPP TS 45.008. It is encoded as follows: 

PR mode A: for one addressed MS 

1 PR mode B: for all MS 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 



11.2.30 (void) 

11. 2.30a Packet Pause 

This optional message is sent on the PACCH from a mobile station with non-GSM capabilities to the network to request 
a pause of GPRS services. 

Message type: PACKET PAUSE 

Direction: mobile station to network 

Table 11.2.30a.1: PACKET PAUSE information elements 

< Packet pause message content > ::= 

< TLLI : bit (32) > 

< RAI : bit (48) > 

< padding bits > ; 

Table 11. 2.30a.2: PACKET PAUSE information element details 

TLLI (32 bit field) 

This field contains the TLLI of the mobile station. This field is encoded as defined in sub-clause 12.16. 

RAI (48 bit field) 

This field contains the Routing Area identification. This field is described in 3GPP TS 44.018. 
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1 1 .2.31 Packet Timeslot Reconfigure 



This message is sent on the PACCH by the network to the mobile station to assign uplink and downlink resources. A 
mobile allocation or reference frequency list received as part of this assignment message shall be valid until a new 
assignment is received or each TBF of the MS are terminated. 

Message type: PACKET TIMESLOT RECONFIGURE 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.31.1: PACKET TIMESLOT RECONFIGURE information elements 

< Packet Timeslot Reconfigure message content > ::= 
< PAGE_MODE : bit (2) > 
{ < GLOBAL_TFI : < Global TFI IE > > 
{ -- Message escape 

{ < CHANNEL_CODING_COMMAND : bit (2) > 

< Global Packet Timing Advance : < Global Packet Timing Advance IE > > 

< DOWNLINK_RLC_MODE : bit (1) > 

< CONTROL_ACK : bit (1 ) > 

{ I 1 < DOWNLINK_TFLASSIGNI\/IENT : bit (5) > } 
{ I 1 < UPLINK_TFI_ASSIGNI\/IENT : bit (5) > } 

< DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

< Dynamic Allocation : < Dynamic Allocation struct > > 

{ null I bit** = < no string > -- Receiver backward compatible with earlier version 

I 1 -- Additions for R99 

{ I 1 < Packet Extended Timing Advance : bit (2) > } 
{ null I bit** = < no string > -- Receiver backward compatible with earlier version 

I 1 -- Additions for REL-5 

{ I 1 < RB Id Of downlink TBF : bit (5) > 

< RB Id of uplink TBF: bit (5) > } 

{ I 1 < Uplink Control Timeslot : bit (3) > } 

{ null I bit** = <no string> -- Receiver backward compatible 

I 1 -- Additions for REL-6 

{ I 1 < PFI of downlink TBF : bit (7) > } 

{ I 1 < PFI of uplink TBF : bit (7) > } 

{ I 1 < UPLINK_RLC_MODE : bit (1 ) > } 

< padding bits > } } } 

! < Non-distribution part error : bit (*) = < no string > > } 
I 1 -- Message escape bit used to define EGPRS message contents 

{ 00 { { I 1 < COMPACT reduced MA : < COMPACT reduced MA IE » } 

< EGPRS Channel Coding Command : < EGPRS Modulation and Coding IE » 
<RESEGMENT:bit(1)> 

{ I 1 < DOWNLINK EGPRS Window Size : < EGPRS Window Size IE > > } 
{ I 1 < UPLINK EGPRS Window Size : < EGPRS Window Size IE > > } 

< LINK_QUALITY_MEASUREMENT_MODE : bit (2) > 

< Global Packet Timing Advance : < Global Packet Timing Advance IE > > 
{ I 1 < Packet Extended Timing Advance : bit (2) > } 

< DOWNLINK_RLC_MODE : bit (1) > 

< CONTROL_ACK : bit (1) > 

{ I 1 < DOWNLINK_TFI_ASSIGNMENT : bit (5) > } 
{ I 1 < UPLINK_TFLASSIGNMENT : bit (5) > } 

< DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 

< Dynamic Allocation : < Dynamic Allocation struct > > 

{ null I bit** = < no string > - Receiver backward compatible with earlier version 
I 1 -- Additions for REL-5 

{ I 1 < RB Id Of downlink TBF : bit (5) > 

< RB Id of uplink TBF: bit (5) > } 

{ I 1 < Uplink Control Timeslot : bit (3) > } 

{ null I bit** = <no string> -- Receiver backward compatible 

I 1 -- Additions for REL-6 

{ I 1 < PFI of downlink TBF : bit (7) > } 

{ I 1 < PFI of uplink TBF : bit (7) > } 

{ I 1 < UPLINK_RLC_MODE : bit (1 ) > } 

< padding bits > } } 

1 < Non-distribution part error : bit {*) = < no string > > } 

I < Message escape : { 01 1 1 | 1 1 } bit (*) = <no string> > }} -Extended for future changes 
! < Address information part error : bit (*) = < no string > > } 
I < Distribution part error : bit (*) = < no string > > ; 
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<Dynamic Allocation struct > ::= 


< EXTENDED DYNAMIC ALLOCATION : bit (1) > 


{0|1 < 


PO : bit (4) > 


< 


PR_M0DE:bit(1)>} 


< USF GRANULARITY : bit (1) > 





-- The value '1 ' was allocated in an earlier version of the protocol and shall not be used. 


{0|1 <■ 


FBF Starting Time : < Starting Frame Number Description IE > > } 


{0 


-- TImeslot Allocation 


{0|1 


< USF TNO : bit (3) > } 


{0|1 


< USF TNI : bit (3) > } 


{0|1 


< USF TN2 : bit (3) > } 


{0|1 


< USF TN3 : bit (3) > } 


{0|1 


< USF TN4 : bit (3) > } 


{0|1 


< USF TN5 : bit (3) > } 


{0|1 


< USF TN6 : bit (3) > } 


{0|1 


< USF_TN7 : bit (3) > } 


I1 


-- TImeslot Allocation with Power Control Parameters 


< ALPHA : bit (4) > 


{0|1 


< USF TNO : bit (3) > 




< GAMMA TNO : bit (5) > } 


{0|1 


< USF TNI : bit (3) > 




< GAMMA TNI : bit (5) > } 


{0|1 


< USF TN2 : bit (3) > 




< GAMMA TN2 : bit (5) > } 


{0|1 


< USF TN3 : bit (3) > 




< GAMMA TN3 : bit (5) > } 


{0|1 


< USF TN4 : bit (3) > 




< GAMMA TN4 : bit (5) > } 


{0|1 


< USF TN5 : bit (3) > 




< GAMMA TN5 : bit (5) > } 


{0|1 


< USF TN6 : bit (3) > 




< GAMMA TN6 : bit (5) > } 


{0|1 


< USF TN7 : bit (3) > 




< GAMMA TN7 : bit (5) > } } ; 



Table 11.2.31.2: PACKET TIMESLOT RECONFIGURE information element details 



Global TFI (6 bit field) 

This field identifies (one of) the uplink TFI, if available, or (one of) the downlink TFI, to which this message applies. 

This field is defined in sub-clause 12.10. 

CHANNEL_CODING_COMMAND (2 bit field) 

The Channel Coding Indicator field indicates the channel coding scheme that the mobile station shall use when 

transmitting on the uplink. 



bit 




2 1 




00 


CS-1 


01 


CS-2 


10 


CS-3 


1 1 


CS-4 



COMPACT reduced MA 

This information element is defined in sub-clause 12.29. 

EGPRS Modulation and Coding Scheme 

The EGPRS modulation and coding scheme information element is defined in sub-clause 12.10d. 

RESEGMENT (1 bit field) 

This field is defined in sub-clause 12.10e. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 
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LINK_QUALITY_MEASUREMENT_MODE (2 bit field) 

This field is encoded as the LINK_QUALITY_MEASUREMENT_MODE IE of the 

PACKET DOWNLINK ASSIGNMENT message, as defined in sub-clause 11.2.7. 

Global Packet Timing Advance 

This information element is defined in sub-clause 12.12a. 

DOWNLINK_RLC_MODE (1 bit field) 

This field indicates the RLC mode of the requested TBF. 

RLC acknowledged mode 

1 RLC unacknowledged mode 

CONTROL_ACK (1 bit field) 

This field shall be set to '1' if the network establishes a new downlink TBF for the mobile station whose timer T3192 is 

running. Otherwise this field shall be set to '0'. 

DOWNLINK_TFI_ASSIGNMENT (5 bit field) 

This information element, if present, assigns the contained TFI to the mobile station to identify a downlink TBF 

described by this message. This field is coded the same as the TFI field defined in sub-clause 12.15. 

UPLINK_TFI_ASSIGNMENT (5 bit field) 

This information element, if present, assigns the contained TFI to the mobile station to identify an uplink TBF described 

by this message. This field is coded the same as the TFI field defined in sub-clause 12.15. 

DOWNLINK_TIMESLOT_ALLOCATION (8 bit field) 
This field is defined in sub-clause 12.18. 

Power Control Parameters 

This information element, if present, contains the power control parameters and timeslot allocation for the uplink TBF. 
If this information element is not present, the MS shall continue to use the previous parameters. This information 
element is defined in sub-clause 12.13. 

Frequency Parameters 

This information element, if present, assigns frequency parameters to the uplink and downlink TBFs. If this information 
element is not present the mobile station shall use its previously assigned frequency parameters. This information 
element is defined in sub-clause 12.8. 

Dynamic Allocation struct 

This information element contains parameters necessary to define the radio resources of a dynamic allocation or an 
extended dynamic allocation. 

EXTENDED_DYNAMIC_ALLOCATION (1 bit field) 

This information field indicates the medium access mode to be used during the TBF. 

Dynamic Allocation 

1 Extended Dynamic Allocation 
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TBF Starting Time 

The TBF Starting Time field contains a starting time that indicates the frame number during which the assigned TBF 
may start. 

If no downhnk TBF is in progress, the mobile station need not monitor the TFI field of downlink RLC data blocks until 
the indicated TDMA frame number. After the indicated TDMA frame number, the mobile station shall apply the new 
downlink parameters and then operate as during a downlink TBF. If a downlink TBF is already in progress, the mobile 
station shall continue to use the parameters of the existing TBF until the TDMA frame number occurs. When the 
indicated TDMA frame number occurs, the mobile station shall immediately begin to use the new downlink parameters 
assigned. 

If no uplink TBF is in progress, the MS need not monitor the USF field until the TDMA frame number occurs. When 
the indicated TDMA frame number occurs, the mobile station shall immediately begin to monitor the USF field and use 
the new assigned uplink TBF parameters when its USF has occurred. If an uplink TBF is already in progress, the MS 
shall continue to use the parameters of the existing TBF until the TDMA frame number occurs. When the indicated 
TDMA frame number occurs, the mobile station shall immediately begin to monitor the USF field and use the new 
assigned uplink TBF parameters when its USF has occurred. 

This field is encoded as the Starting Frame Number Description IE. See sub-clause 12.21 

USF for Timeslot Number (TNO) (3 bit field) 
USF for Timeslot Number 1 (TNI) (3 bit field) 
USF for Timeslot Number 2 (TN2) (3 bit field) 
USF for Timeslot Number 3 (TN3) (3 bit field) 
USF for Timeslot Number 4 (TN4) (3 bit field) 
USF for Timeslot Number 5 (TN5) (3 bit field) 
USF for Timeslot Number 6 (TN6) (3 bit field) 
USF for Timeslot Number 7 (TN7) (3 bit field) 

These fields indicate the USF value assigned to the MS for timeslots to 7. These fields are encoded as a binary 
presentation of the USF value as defined in sub-clause 10.4.1. 

ALPHA (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 

GAMMA_TN (5 bit field) 

The GAMMA_TN field is the binary representation of the parameter FCH for MS output power control in units of 2 

dB, see 3GPP TS 45.008. The GAMMA_TN field is coded according to the following table: 

bit 

5432 1 

FCH = dB 

1 FCH = 2 dB 

11110 FCH = 60 dB 

11111 FCH = 62 dB 

USF_GRANULARITY (1 bit field) 

This information field indicates the USF granularity to be applied by the mobile station when it is assigned a TBF using 

Dynamic Allocation or Extended Dynamic Allocation. 

the mobile station shall transmit one RLC/MAC block 

1 the mobile station shall transmit four consecutive RLC/MAC blocks 

PO (4 bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

PR_MODE(l bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 
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RB Id of downlink TBF (5 bit field) 

RB Id of uplink TBF (5 bit field) 

These fields are included when this message is used to reconfigure TBFs in lu mode. These fields contain the radio 
bearer identifier for the radio bearer using the assigned TBF. 

Uplink Control Timeslot (3 bit field) 

This field contains the timeslot number of the timeslot where the PACCH/U for the downlink TBF is located. It is 

encoded as the binary representation of the timeslot number as defined in 3GPP TS 45.002. 

PFI of downlink TBF (7 bit field) 

PFI of uplink TBF (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context related to the TBF identified in the 

DOWNLINK_TFI_ASSIGMENT field or UPLINK_TFI_ASSIGMENT field respectively. The PFI parameter is 

encoded as the contents of the PFI information element as defined in 3GPP TS 44.018. 

UPLINK_RLC_MODE (1 bit field) 

This field contains the RLC mode to be used for the assigned TBF. If a new mode is assigned by the network for an 

already established TBF, the MS shall ignore the new assigned mode and shall maintain the TBF in the old mode. 

RLC acknowledged mode 

1 RLC unacknowledged mode 



1 1 .2.31 .1 Special requirements in dual transfer mode 

Special requirements apply when a TBF is assigned to a mobile station in dual transfer mode or about to enter dual 
transfer mode, see sub-clauses 11.2.7.1 and 11.2.29.1 of the present document. 



1 1 .2.31 a Multiple TBF Timeslot Reconfigure 



This message is sent on the PACCH by the network to the mobile station to assign uplink and downlink resources. A 
mobile allocation or reference frequency list received as part of this assignment message shall be valid until a new 
assignment is received or each TBF of the MS are terminated. 

Message type: MULTIPLE TBF TIMESLOT RECONFIGURE 

Direction: network to mobile station 

Classification: non-distribution message 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 333 ETSI TS 1 44 060 V6.28.0 (201 0-03) 

Table 1 1 .2.31a.1 : MULTIPLE TBF TIMESLOT RECONFIGURE information elements 

< Multiple TBF Timeslot Reconfigure message content > ::= 

< PAGE_MODE : bit (2) > 

{ < GLOBAL_TFI : < Global TFI IE > > 

{ -- Message escape for GPRS mode TBFs 

{ { I 1 < CHANNEL_CODING_COMMAND : bit (2) > } 

< Global Packet Timing Advance : < Global Packet Timing Advance IE > > 
{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

{ I 1 < Packet Extended Timing Advance : bit (2) > } 

{ 1 < IVIultiple Downlink Assignment : < IVIultiple Downlink Assignment struct > > } ** 

< Multiple Uplink Assignment : < Multiple Uplink Assignment struct > > 

< padding bits > } 

! < Non-distribution part error : bit (*) = < no string > > } 
I 1 -- Message escape bit for EGPRS mode TBFs 

{00{ 

{ I 1 < EGPRS Channel Coding Command : < EGPRS Modulation and Coding IE > > } 

<RESEGMENT:bit(1)> 

{ I 1 < Downlink EGPRS Window Size : < EGPRS Window Size IE > } 

{ I 1 { |1 < Uplink EGPRS Window Size : < EGPRS Window Size IE > > } 

< LINK_QUALITY_MEASUREMENT_MODE : bit (2) > 
{ I 1 < BEP_PERI0D2 : bit(4) > } } 

< Global Packet Timing Advance : < Global Packet Timing Advance IE > > 
{ I 1 < Packet Extended Timing Advance : bit (2) > } 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

{ 1 < Multiple Downlink Assignment : < Multiple Downlink Assignment struct > > } ** 

< Multiple Uplink Assignment : < Multiple Uplink Assignment struct > > 

< padding bits > } 

! < Non-distribution part error : bit (*) = < no string > > } 
I < Message escape : { 01 1 1 | 11 } bit (*) = < no string > > } -Extended for future ctianges 
! < Address information part error : bit (*) = < no string > > } 
I < Distribution part error : bit (*) = < no string > > ; 

< Multiple Downlink Assignment struct > ::= 

< TIMESLOT_ALLOCATION : bit (8) > 

{ I 1 < Uplink Control Timeslot : bit (3) > } 

{ 1 < Downlink TBF assignment : < Downlink TBF assignment struct > > } ** ; 

< Downlink TBF assignment struct > :: = 

{ < RB Id : bit (5) > 
I 1 < PFI : bit (7) > 

<RLC_M0DE:bit(1)>} 
{ I 1 < Uplink Control Timeslot : bit (3) > } 

< TFI Assignment : bit (5) > 

< CONTROL_ACK : bit (1) > 

{ I 1 < Downlink EGPRS Window Size : < EGPRS Window Size IE > > } ; 

< Multiple Uplink Assignment struct > ::= 

< EXTENDED_DYNAMIC_ALLOCATION : bit (1) > 
{ I 1 < PO : bit (4) > 

<PR_M0DE:bit(1)>} 
{ I 1 < TBF Starting Time : < Starting Frame Number Description IE > > } 
{ I 1 < Global Timeslot description : < Timeslot description struct > > 

{ 1 < Uplink TBF Assignment : < Uplink TBF Assignment struct > > } ** } ; 
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< Timeslot description struct > : 


:= 


{0 




< MS_TIMESLOT_ALLOCATION : 

1 H 


1 1 

< ALPHA : bit (4) > 




{ 1 1 < GAMMA TNO 


bit (5) > } 


{ |1 < GAMMA TNI 


bit (5) > } 


{ 1 1 < GAMMA TN2 


bit (5) > } 


{ 1 1 < GAMMA TN3 


bit (5) > } 


{ 1 1 < GAMMA TN4 


bit (5) > } 


{ |1 < GAMMA TN5 


bit (5) > } 


{ 1 1 < GAMMA TN6 


bit (5) > } 


{ |1 < GAMMA TN7 


bit (5) > } } 



bit (8) > 



without power control params 
with power control params 



< Uplinl< TBF Assignment struct > 
{ < RB Id : bit (5) > 
I 1 < PFI : bit (7) > } 

<RLC_M0DE:bit(1)>} 

< TFI Assignment : bit (5) > 
{ I 1 < CHANNEL_CODING 
{0|1 
{ I 1 < Uplink EGPRS Window Size 

< USF_GRANULARITY : bit (1) > 
{0 



Recursive for multiple TBFs 



1 < TBF_TIMESLOT_ALLOCATION : bit (N) > } 



{0 
M 



COMMAND : bit (2) > } 
< EGPRS Channel Coding Command : < EGPRS Modulation and Coding Scheme IE > > } 

< EGPRS Window Size IE > > } 

-- The timesiots assigned to the TBF are all the timeslots assigned 
in the Global Timeslot description 

- The timesiots assigned to the TBF are a subset of all the 
-- timesiots assigned in the Global Timeslot description. Where 

- N is the amount of timesiots assigned to the IViS in the Global 

- Timeslot description 

- The same USF is valid on all timesiots assigned to the TBF 

- Different USF(s) assigned 
-- USF assignment on the lowest numbered timeslot 
-- assigned to the TBF 

(M-1 ) } ; -- USFs on subsequent timesiots assigned to the TBF: 
-A '0' (respectively a '1 ' followed by a USF value) 
-- means same (respectively different) USF value as the 
-- USF on the next lower numbered timeslot assigned to 
-- the TBF. Where M is the amount of timesiots assigned 
- to the TBF in the TBF_TIMESLOT_ALLOCATION if 
-- present, else in the Global Timeslot description 



< USF_ALLOCATION : bit (3) > 

< USF_ALLOCATION : bit (3) > 

{ I 1 < USF_ALLOCATION : bit (3) > } 



Table 11. 2.31a.2: MULTIPLE TBF TIMESLOT RECONFIGURE information element details 

Global TFI 

This information element identifies one of the mobile station's downlink or uplink TFIs. This field is defined in sub- 
clause 12.10. 
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CHANNEL_CODING_COMMAND (2 bit field) 

The Channel Coding Indicator field indicates the channel coding scheme that the mobile station shall use when 
transmitting on the uplink. If this field is included in the main body of the message, it shall refer to all GPRS TBF mode 
uplink TBFs assigned in the message (default value). If this field is included in the Uplink TBF Assignment struct, it 
refers only to the TBF given by the TFI Assignment (this specific value overrules the default value). Every uplink TBF 
defined in GPRS TBF mode shall be assigned either the default value or a specific value. 



bit 




21 




00 


CS-1 


01 


CS-2 


10 


CS-3 


1 1 


CS-4 



EGPRS Modulation and Coding SchemeThe EGPRS modulation and coding scheme information element is defined 
in sub-clause 12.10d. 

If this field is included in the main body of the message, it shall refer to all EGPRS TBF mode uplink TBFs assigned in 
the message (default value). If this field is included in the Uplink TBF Assignment struct, it refers only to the TBF 
given by the TFI Assignment (this specific value overrules the default value). Every uplink TBF defined in EGPRS 
TBF mode shall be assigned either the default value or a specific value. 

RESEGMENT (1 bit field) 

This field is defined in sub-clause 12.10e. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

If this field is included in the main body of the message, it shall refer to all TBFs assigned in the message in the 
direction indicated (default value). If this field is included in the respective TBF Assignment struct (uplink or 
downlink), it refers only to the TBF given by the TFI Assignment (this specific value overrules the default value). 
Every TBF defined in EGPRS TBF mode shall be assigned either the default value or a specific value. 

LINK_QUALITY_MEASUREMENT_MODE (2 bit field) 

This field is encoded as the LINK_QUALITY_MEASUREMENT_MODE IE of the 

PACKET DOWNLINK ASSIGNMENT message, as defined in sub-clause 1 1.2.7. 

Global Packet Timing Advance 

This information element is defined in sub-clause 12.12a. 

CONTROL_ACK (1 bit field) 

This field shall be set to "1" if the network wishes to instruct the mobile station to release the given TBFs for which 
T3192 is running. The TBFs to be released are identified by the TFIs given in the TFI Assignment field and have to be 
valid on the PACCH on which this message was sent. Otherwise this field shall be set to "0". 

TFI Assignment (5 bit field) 

This information element assigns one (or more) TFI(s) to each TBF assigned to the mobile station in this message. This 
field is repeated for each TBF that is assigned in this message. Optionally, this field may be repeated for each timeslot 
on which the TBF has been assigned resources. This is in order to assign different TFI values for the same TBF on 
different resources (BPSCH). TFI values are encoded as defined in sub-clause 12.15. 

RB Id (5 bit field) 

This field contains the radio bearer identifier for the radio bearer using the assigned TBF. This provides the mapping of 

TFI to RB Id which is necessary to uniquely identify lu-mode data flows. 
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Uplink Control Timeslot (3 bit field) 

This field contains the timeslot number of the timeslot where the PACCH/U for the MS is located. It is encoded as the 

binary representation of the timeslot number as defined in 3GPP TS 45.002. 

If this field is included in the Multiple Downlink Assignment struct, it shall refer to all downlink TBFs assigned in the 
message. If this field is included in the Downlink TBF assignment struct, it refers only to the TBF given by the TFI 
Assignment field (this specific value overrules any default value given in the Multiple Downlink Assignment struct). If 
the Uplink Control Timeslot field is not included in the message at all, then the default rules for the location of 
PACCH/U apply. 

TIMESLOT_ALLOCATION (8 bit field) 
This field is defined in sub-clause 12.18. 

Power Control Parameters 

This information element, if present, contains the power control parameters and timeslot allocation for the uplink TBF. 
If this information element is not present, the MS shall continue to use the previous parameters. This information 
element is defined in sub-clause 12.13. 

Frequency Parameters 

This information element, if present, assigns frequency parameters to the uplink and downlink TBFs. If this information 
element is not present the mobile station shall use its previously assigned frequency parameters. This information 
element is defined in sub-clause 12.8. 

EXTENDED_DYNAMIC_ALLOCATION (1 bit field) 

This information field indicates the medium access mode to be used during the TBF. 

Dynamic Allocation 

1 Extended Dynamic Allocation 

TBF Starting Time 

The TBF Starting Time field contains a starting time that indicates the frame number during which the assigned TBF 

may start. 

If no downlink TBF is in progress, the mobile station need not monitor the TFI field of downlink RLC data blocks until 
the indicated TDMA frame number. After the indicated TDMA frame number, the mobile station shall apply the new 
downlink parameters and then operate as during a downlink TBF. If a downlink TBF is already in progress, the mobile 
station shall continue to use the parameters of the existing TBF until the TDMA frame number occurs. When the 
indicated TDMA frame number occurs, the mobile station shall immediately begin to use the new downlink parameters 
assigned. 

In case of dynamic allocation, if no uplink TBF is in progress, the MS need not monitor the USF field until the TDMA 
frame number occurs. When the indicated TDMA frame number occurs, the mobile station shall immediately begin to 
monitor the USF field and use the new assigned uplink TBF parameters when its USF has occurred. If an uplink TBF is 
already in progress, the MS shall continue to use the parameters of the existing TBF until the TDMA frame number 
occurs. When the indicated TDMA frame number occurs, the mobile station shall immediately begin to monitor the 
USF field and use the new assigned uplink TBF parameters when its USF has occurred. 

This field is encoded as the Starting Frame Number Description IE. See sub-clause 12.21 

MS_TIMESLOT_ALLOCATION (8 bit field) 

This information field indicates the timeslots assigned for use by the MS for the assigned uplink TBFs. Bit 8 indicates 

the status of timeslot 0, bit 7 indicates the status of timeslot 1, etc. At least one timeslot must be assigned. 

Timeslot is not assigned 

1 Timeslot is assigned 
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TBF_TIMESLOT_ALLOCATION (N bit field) 

This information field indicates the timeslots assigned to a particular uplink TBF, within the timeslots assigned to the 
MS in the Global Timeslot description. This field contains as many bits as there are timeslots assigned to the MS in the 
Global Timeslot description. Bit N indicates the status of the lowest numbered timeslot in the timeslots assigned to the 
MS in the Global Timeslot description. Bit N-1 (if any) indicates the status of the next lowest numbered timeslot, etc. 
At least one timeslot must be assigned per TBF 

Timeslot is not assigned 

1 Timeslot is assigned 

USF_ALLOCATION (3 bit field) 

This field indicates the USF value assigned to the MS for one or more allocated timeslots. This field is encoded as a 
binary presentation of the USF value as defined in sub-clause 10.4.1. 

USF_GRANULARITY (1 bit field) 

This information field indicates the USF granularity to be applied by the mobile station when it is assigned a TBF using 

Dynamic Allocation or Extended Dynamic Allocation. 

the mobile station shall transmit one RLC/MAC block 

1 the mobile station shall transmit four consecutive RLC/MAC blocks 

ALPHA (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 

GAMMA_TN (5 bit field) 

The GAMMA_TN field is the binary representation of the parameter FCH for MS output power control in units of 2 

dB, see 3GPP TS 45.008. The GAMMA_TN field is coded according to the following table: 



bit 






54321 






00000 


rcH = 


= OdB 


00001 


rcH = 


= 2dB 


11110 


rcH = 


= 60dB 


11111 


rcH = 


= 62dB 



PO (4 bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

PR_MODE(l bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 

PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context. The PFI parameter is encoded as the contents 
of the PFI information element as defined in 3GPP TS 44.018. 

RLC_MODE (1 bit field) 

This field contains the RLC mode to be used for the assigned TBF. If a new mode is assigned by the network for an 
already established TBF, the MS shall ignore the new assigned mode and shall maintain the TBF in the old mode. 

RLC acknowledged mode 

1 RLC unacknowledged mode 
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1 1 .2.32 Additional MS Radio Access Capabilities 

This message is sent on the PACCH by the mobile station to the network to inform about radio access capabihties of the 
mobile station. It shall not be used in lu mode. 

Message type: Additional MS Radio Access Capabilities 

Direction: mobile station to network 

Table 11.2.32.1: ADDITIONAL MS RADIO ACCESS CAPABILITIES information elements 

< Additional IVIS Radio Access Capabilities message content > ::= 
{ < Global TFI : < Global TFI IE > > 
I 1 <TLLI:<TLLI IE > > } 

< MS Radio Access Capability 2 : < MS Radio Access Capability 2 IE > > 

< padding bits > ; 

Table 11.2.32.2: ADDITIONAL MS RADIO ACCESS CAPABILITIES information element details 

Global TFI 

This information element contains the TFI of the mobile station's uplink TBF, if available, or the TFI of the mobile 
station's downlink TBF. If no TFI is available, this field is omitted. This field is defined in sub-clause 12.10. 

TLLI IE (32 bit field) 

This information element is defined in sub-clause 12.16. 

MS Radio Access Capability 2 

This information element is defined in sub-clause 12.30. This information element is sent during one phase and two 

phase access procedures. 



1 1 .2.33 Handover Access {lu mode only) 

This message is sent on DBPSCH on either PACCH, FACCH or SDCCH and optionally on SACCH by the mobile 
station to the network during a handover procedure as specified in 3GPP TS 44.160 and 3GPP TS 44.1 18. It shall not be 
sent on the 52-multiframe structure (SBPSCH). This message is formatted as four identical access bursts on PACCH, 
FACCH and SDCCH, and as one individual access burst on SACCH. Each access burst shall use the 8-bit access burst 
format and follow the 8-bit PRACH uplink/PACCH uplink short acknowledgement block format defined in 
3GPP TS 44.004. Each access burst is coded as shown in table 11.2.33.1. The order of bit transmission is defined in 
3GPP TS 44.004. The numbering, assembling and field mapping conventions defined for RLC/MAC control blocks in 
sub-clause 10.0b shall apply. 

Direction: mobile station to network 

Table 11.2.33.1: HANDOVER ACCESS information elements 

< Handover Access 8 bit message > ::= - 8-bit access burst format 

< HANDOVER_REFERENCE_VALUE : bit (8) >; 

Table 11.2.33.2: HANDOVER ACCESS information element details 

HANDOVER_REFERENCE_VALUE (8 bit field) 

This field is coded as the handover reference value field defined in 3GPP TS 44.018. 
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1 1 .2.34 Physical Information {lu mode only) 



This message is sent on DBPSCH on either PACCH, FACCH or SDCCH by the network to the mobile station during a 
handover procedure as specified in 3GPP TS 44.160 and 3GPP TS 44.1 18 to indicate a valid timing advance to the 
mobile station. It shall not be sent on the 52-multiframe structure (SBPSCH). 

Message type: PHYSICAL INFORMATION 

Direction: network to mobile station 

Classification: DBPSCH message 

Table 11.2.34.1: PHYSICAL INFORMATION information elements 

< Physical information message content > ::= - RLC/MAC control block format 

< MESSAGE_TYPE : bit (6) == 010010 > 

< TIMING_ADVANCE_VALUE : bit (8) > 

< padding bits >; -- truncation at end of message allowed, bits '0' assumed 

Table 11.2.34.2: PHYSICAL INFORMATION information element details 

TIMING_ADVANCE_VALUE (8 bit field) 

This field is coded as the timing advance value field defined in 3GPP TS 44.018. 



1 1 .2.35 Packet CS Request 

This message is sent from the mobile station to the network on the PACCH to request RR connection. 
Message type: PACKET CS REQUEST 
Direction: mobile station to network 

Table 11.2.35.1: PACKET CS REQUEST information elements 

< Pacl<et CS Request message content > ::= 

< GLOBAL TFI : < Global TFI IE > > 

< ESTABLISHMENT CAUSE : bit (8) > 

< padding bits > ; 

Table 11.2.35.2: PACKET CS REQUEST information element details 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

ESTABLISHMENT CAUSE (8 bit field) 

The ESTABLISHMENT CAUSE field indicates the cause value of the RR connection establishment. This field is 
specified in 3GPP TS 44.018. The mobile station shall neither use cause values referring to answer to paging nor 
request of PDCH. 



1 1 .2.36 Packet CS Command 

This optional message is sent by the network on the PACCH to encapsulate RR control messages. This message may be 
segmented across more than two RLC/MAC control block by using extended RLC/MAC control message segmentation. 

Message type: PACKET CS COMMAND 

Direction: network to mobile station 
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Classification: non distribution message 

Table 11.2.36.1: Packet CS Command information elements 



< Packet CS Command message content > ::= 






< PAGE MODE : bit (2) > 






{ < GLOBAL TFI :< Global TFI IE >> 






{ < spare : bit (2) > 






< CONTAINER LENGTH : bit (8) > 






< CONTAINER DATA : octet ** > 






< padding bits > 






! < Non-distribution part error : bit (*) = 


< no 


string > > } 


! < Address information part error : bit (*) = 


= < nc 


) string > > } 


! < Distribution part error : bit (*) = < no string 


> > ; 





Table 11.2.36.2: Packet CS Command information element details 



The Packet CS Command message encapsulates RR control message (e.g. DTM ASSIGNMENT COMMAND, 
IMMEDIATE ASSIGNMENT or IMMEDIATE ASSIGNMENT REJECT). 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20 and gives the PAGE_MODE parameter valid in the serving cell. 

GlobaLTFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

CONTAINER_LENGTH (8 bit field) 

This field indicates the number of CONTAINER_D ATA octets that form the specific RR control message and is coded 

as shown below. 

Bit 

87654321 

00000000 No CONTAINER_DATA follows; Spare padding is used to fill the rest of the message; 

1 CONTAINER_DATA length = 1 octet; 

10 10 10 CONTAINER_DATA length = 168 octets; 

All other values reserved. If a reserved value is received the contents of the container shall be discarded. 

CONTAINER DATA (n*8 bits) 

The CONTAINER DATA octets forms the actual RR control message content. The information contained in the Packet 
CS Command message shall exclude the following information elements from the beginning of the RR control 
message: L2 Pseudo Length; RR management Protocol Discriminator and Skip Indicator. 

Extra octets of padding bits at the end of the RR control message may be excluded. 



1 1 .2.37 Packet CS Release Indication 

This message is sent from the network to the mobile station on the PACCH to indicate that the ongoing RR connection 
will be released. The network may indicate that the mobile station shall maintain its uplink and downlink packet 
resources used in dual transfer mode or it may convert half-rate PDCH into full-rate PDCH to be used in packet transfer 
mode or it may reconfigure uplink and/or downlink packet resources to be used in packet transfer mode after the RR 
connection is released. This message shall not be segmented across more than two RLC/MAC control block by using 
the procedures specified in sub-clause 9.1.12a. A mobile allocation or reference frequency list received as part of this 
assignment message shall be valid until a new assignment is received or each TBF of the MS are terminated. 

With reconfiguration option the network shall assign at least one uplink or downlink TBF. 

Message type: PACKET CS RELEASE INDICATION 
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Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.37.1: PACKET CS RELEASE INDICATION information elements 

< Packet CS Release message content > ::= 
< PAGE_MODE : bit (2) > 

{ < GLOBAL_TFI : < Global TFI IE > > 

< ENHANCED_DTM_CS_RELEASEJNDICATION : bit > 

< Global Packet Timing Advance : < Global Packet Timing Advance IE > > 

{ 00 -- RR connection is released and the MS maintains its DL and/or UL TBF(s) 

I 01 -- Wiien RR connection is released, PDTCH/H is converted to PDTCH/F and the MS maintains 

its DL and/or UL TBF(s) 

I 1 -- RR connection is released and DL and/or UL TBF(s) are reconfigured 

{ -- Message escape for GPRS mode TBFs 

{ { I 1 < Frequency Parameters : < Frequency Parameters IE > > } 
{ I 1 < PACKET_EXTENDED_TIMING_ADVANCE : bit (2) > } 
{ I 1 -- downlink TBF(s) 

{ 1 < Multiple Downlink Assignment : < Multiple Downlink Assignment struct > > } ** 

} 

{ I 1 -- uplink TBF(s) 

{ I 1 < CHANNEL_CODING_COMMAND : bit (2) > } 

< Multiple Uplink Assignment : < Multiple Uplink Assignment struct > > } 
< padding bits > 
! < Non-distribution part error : bit (*) = < no string > > } 
I 1 -- Message escape bit for EGPRS mode TBFs 



{00 



**0} 

Scheme IE » } 



{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 
{ I 1 < PACKET_EXTENDED_TIMING_ADVANCE : bit (2) > } 
{ I 1 < BEP_PERI0D2 : bit(4) > } 
{ I 1 -- downlink TBF(s) 

{ I 1 < Downlink EGPRS Window Size : < EGPRS Window Size IE > > } 

< LINK_QUALITY_MEASUREMENT_MODE : bit (2) > 

{ 1 < Multiple Downlink Assignment : < Multiple Downlink Assignment struct > > } 

{ I 1 -- uplink TBF(s) 

{ I 1 < EGPRS Channel Coding Command : < EGPRS Modulation and Coding 



<RESEGMENT:bit(1)> 
{ I 1 < Uplink EGPRS Window Size : < EGPRS Window Size IE > > } 
< Multiple Uplink Assignment : < Multiple Uplink Assignment struct > > } 
< padding bits > 

! < Non-distribution part error : bit {*) = < no string > > } 
! < Message escape : { 01 1 1 | 1 1 } bit (*) = < no string > > } } -Extended for future changes 
I 1 1 } - Reserved for future use. When received it shall be interpreted as "00". 
! < Address information part error : bit {*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 

< Multiple Downlink Assignment struct > ::= 

< TIMESLOT_ALLOCATION : bit (8) > 

{ I 1 < UPLINK_CONTROL_TIMESLOT : bit (3) > } 

{ 1 < Downlink TBF assignment : < Downlink TBF assignment struct > > } ** ; 

< Downlink TBF assignment struct > :: = 

{ I 1 < PFI : bit (7) > } 

< DOWNLINK_RLC_MODE : bit (1) > 

{ I 1 UPLINK_CONTROL_TIMESLOT : bit (3) > } 

< TFLASSIGNMENT : bit (5) > 

< CONTROL_ACK : bit (1 ) > 

{ I 1 < Downlink EGPRS Window Size : < EGPRS Window Size IE > > } ; 

< Multiple Uplink Assignment struct > ::= 

< EXTENDED_DYNAMIC_ALLOCATION : bit (1) > 
{ I 1 < PO : bit (4) > 

<PR_M0DE:bit(1)>} 
{ I 1 < Global Timeslot description : < Timeslot description struct > > 
{ 1 < Uplink TBF Assignment : < Uplink TBF Assignment struct > > } ** } ; 
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< Timeslot description struct > ::= 
{0 

< MS_TIMESLOT_ALLOCATION 

I 1 



-- without power control params 
bit (8) > 

-- with power control params 



< ALPHA : bit (4) > 




{ 1 1 < GAMMA TNO 


bit (5) > } 


{ 1 1 < GAMMA TNI 


bit (5) > } 


{ 1 1 < GAMMA TN2 


bit (5) > } 


{ 1 1 < GAMMA TN3 


bit (5) > } 


{ 1 1 < GAMMA TN4 


bit (5) > } 


{ 1 1 < GAMMA TN5 


bit (5) > } 


{ 1 1 < GAMMA TN6 


bit (5) > } 


{ 1 1 < GAMMA TN7 


bit (5) > } } 



< Uplink TBF Assignment struct > ::= -- Recursive for multiple TBFs 

{ I 1 < PFI : bit (7) > } 
< TFLASSIGNMENT : bit (5) > 

{ I 1 < CHANNEL_CODING_COMMAND : bit (2) > } 
{ I 1 < EGPRS Channel Coding Command : < EGPRS IVIodulation and Coding Sclieme IE > > } 



{ |1 < Uplink EGPRS Window Size 
< USF_GRANULARITY : bit (1) > 

{0 



EGPRS Window Size IE > > } 



{0 

I 1 



-- The timesiots assigned to the TBF are ail the timesiots assigned 

- in the Global Timeslot description 

1 < TBF_TIMESLOT_ALLOCATION : bit (N) > } -- The timesiots assigned to the TBF are a subset of all the 

-- timesiots assigned in the Global Timeslot description. Where 

- N is the amount of timesiots assigned to the MS In the Global 

- Timeslot description 
-- The same USF is valid on ail timesiots assigned to the TBF 

- Different USF(s) assigned 

- USF assignment on the lowest numbered timeslot 

- assigned to the TBF 
{ I 1 < USF_ALLOCATION : bit (3) > } * {IVI-1 ) } ; -- USFs on subsequent timesiots assigned to the TBF: 

-A V (respectively a'V followed by a USF value) 

- means same (respectively different) USF value as the 

- USF on the next lower numbered timeslot assigned to 

- the TBF. Where M is the amount of timesiots assigned 

- to the TBF in the TBF_TIMESLOT_ALLOCATION if 

- present, else in the Global Timeslot description 



USF_ALLOCATION : bit (3) 
USF_ALLOCATION : bit (3) 



Table 11.2.37.2: PACKET CS RELEASE INDICATION information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

GlobaLTFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

ENHANCED_DTM_CS_RELEASE_INDICATION (1 bit field) 

The ENHANCED_DTM_CS_RELEASE_INDICATION parameter indicates that the network releases the RR 

connection while the mobile station is in dual transfer mode. 

The RR connection is not released. 

1 The RR connection is released. 

NOTE: The network should not use value "0" if the PACKET CS RELEASE INDICATION message is used with 
enhanced DTM CS release procedure. In this case the mobile station shall ignore the message. 

Global Packet Timing Advance 

This information element is defined in sub-clause 12.12a. 
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CHANNEL_CODING_COMMAND (2 bit field) 

The Channel Coding Indicator field indicates the channel coding scheme that the mobile station shall use when 

transmitting on the uplink. 



bit 




2 1 




00 


CS-1 


01 


CS-2 


10 


CS-3 


1 1 


CS-4 



Frequency Parameters 

This information element, if present, assigns frequency parameters to the uplink and downlink TBFs. If this information 
element is not present the mobile station shall use its previously assigned frequency parameters. This information 
element is defined in sub-clause 12.8. 

PACKET_EXTENDED_TIMING_AD VANCE (2 bit field) 
This field is defined in sub-clause 12.12b. 

TIMESLOT_ALLOCATION (8 bit field) 
This field is defined in sub-clause 12.18. 

UPLINK_CONTROL_TIMESLOT (3 bit field) 

This field contains the timeslot number of the timeslot where the PACCH/U for the downlink TBF is located. It is 

encoded as the binary representation of the timeslot number as defined in 3GPP TS 45.002. 

If this field is included in the Multiple Downlink Assignment struct, it shall refer to all downlink TBFs assigned in the 
message. If this field is included in the Downlink TBF assignment struct, it refers only to the TBF given by the TFI 
Assignment field (this specific value overrules any default value given in the Multiple Downlink Assignment struct). If 
the Uplink Control Timeslot field is not included in the message at all, then the default rules for the location of 
PACCH/U apply. 

PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context. The PFI parameter is encoded as the contents 

of the PFI information element as defined in 3GPP TS 44.018. 

DOWNLINK_RLC_MODE (1 bit field) 

This field indicates the RLC mode of the requested TBF. 

RLC acknowledged mode 

1 RLC unacknowledged mode 

TFI_ASSIGNMENT (5 bit field) 

This information element assigns one (or more) TFI(s) to each TBF assigned to the mobile station in this message. This 

field is repeated for each TBF that is assigned in this message. Optionally, this field may be repeated for each timeslot 

on which the TBF has been assigned resources. TFI values are encoded as defined in sub-clause 12.15. 

CONTROL_ACK (1 bit field) 

If multiple TBFs are supported by both network and mobile station, this field shall be set to " 1 " if the network wishes to 

instruct the mobile station to release the given TBFs for which T3192 is running. The TBFs to be released are identified 

by the TFIs given in the TFI Assignment field and have to be valid on the PACCH on which this message was sent. 

Otherwise this field shall be set to "0". 

If either the network or the mobile station does not support the multiple TBF feature, this field shall be set to '1' if the 

network establishes a new downlink TBF for the mobile station whose timer T3192 is running. Otherwise this field 

shall be set to '0'. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

If this field is included in the main body of the message, it shall refer to all TBFs assigned in the message in the 
direction indicated (default value). If this field is included in the respective TBF Assignment struct (uplink or 
downlink), it refers only to the TBF given by the TFI Assignment (this specific value overrules the default value). 
Every TBF defined in EGPRS TBF mode shall be assigned either the default value or a specific value. 
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EGPRS Modulation and Coding Scheme 

The EGPRS modulation and coding scheme information element is defined in sub-clause 12.10d. 

If this field is included in the main body of the message, it shall refer to all EGPRS TBF mode uplink TBFs assigned in 

the message (default value). If this field is included in the Uplink TBF Assignment struct, it refers only to the TBF 

given by the TFI Assignment (this specific value overrules the default value). Every uplink TBF defined in EGPRS 

TBF mode shall be assigned either the default value or a specific value. 

RESEGMENT (1 bit field) 

This field is defined in sub-clause 12.10e. 

LINK_QUALITY_MEASUREMENT_MODE (2 bit field) 

This field is encoded as the LINK_QUALITY_MEASUREMENT_MODE IE of the PACKET DOWNLINK 

ASSIGNMENT message, as defined in sub-clause 11.2.7. 

BEP_PERIOD2 (4 bit field) 

This field contains a constant which is used for filtering channel quality measurements in EGPRS. BEP_PERIOD2 

when present, or if not, when received in a previous message of the same TBF session, shall be used instead of 

BEP_PERIOD. For details see 3GPP TS 45.008. 

Range: to 15 

EXTENDED_DYNAMIC_ALLOCATION (1 bit field) 

This information field indicates the medium access mode to be used during the TBF. 

Dynamic Allocation 

1 Extended Dynamic Allocation 
PO (4 bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

PR_MODE(l bit field) 

For description and encoding, see the Packet Uplink Assignment message. 

MS_TIMESLOT_ALLOCATION (8 bit field) 

This information field indicates the timeslots assigned for use by the MS for the assigned uplink TBFs. Bit 8 indicates 

the status of timeslot 0, bit 7 indicates the status of timeslot 1, etc. At least one timeslot must be assigned. 

Timeslot is not assigned 

1 Timeslot is assigned 
Power Control Parameters 

This information element, if present, contains the power control parameters and timeslot allocation for the uplink TBF. 
If this information element is not present, the MS shall continue to use the previous parameters. This information 
element is defined in sub-clause 12.13. 

ALPHA (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 

GAMMA_TN (5 bit field) 

The GAMMA_TN field is the binary representation of the parameter FCH for MS output power control in units of 2 

dB, see 3GPP TS 45.008. The GAMMA_TN field is coded according to the following table: 

bit 

5432 1 

000 rCH = OdB 

1 FCH = 2 dB 

11110 FCH = 60 dB 

11111 FCH = 62 dB 
USF_GRANULARITY (1 bit field) 

This information field indicates the USE granularity to be applied by the mobile station when it is assigned a TBF using 
Dynamic Allocation or Extended Dynamic Allocation. 

the mobile station shall transmit one RLC/MAC block 

1 the mobile station shall transmit four consecutive RLC/MAC blocks 
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TBF_TIMESLOT_ALLOCATION (N bit field) 

This information field indicates the timeslots assigned to a particular uplink TBF, within the timeslots assigned to the 
MS in the Global Timeslot description. This field contains as many bits as there are timeslots assigned to the MS in the 
Global Timeslot description. Bit N indicates the status of the lowest numbered timeslot in the timeslots assigned to the 
MS in the Global Timeslot description. Bit N-1 (if any) indicates the status of the next lowest numbered timeslot, etc. 
At least one timeslot must be assigned per TBF 

Timeslot is not assigned 

1 Timeslot is assigned 
USF_ALLOCATION (3 bit field) 

This field indicates the USE value assigned to the MS for one or more allocated timeslots. This field is encoded as a 
binary presentation of the USF value as defined in sub-clause 10.4.1. 



1 1 .2.38 MBMS Service Request 



This message is sent on the PACCH from a mobile station to the network in order to inform about the interest in an 
MBMS session. 

Message type: MBMS SERVICE REQUEST 

Direction: mobile station to network 

Table 11.2.38.1: MBMS SERVICE REQUEST information elements 

< MBMS service request message content > ::= 

< TLLI : bit (32) > 

< TMGI : < TMGI struct > > 

{ I 1 < MBMS Session Identity : bit (8) > } 

< MSJD Request Indication : bit (1) > 

< padding bits > ; 



Table 11.2.38.2: MBMS SERVICE REQUEST information element details 

TLLI (32 bit field) 

This field contains the TLLI of the mobile station. This field is encoded as defined in sub-clause 12.16. 

TMGI 

This field contains the Temporary Mobile Group Identity of the MBMS service that is requested by the mobile station. 
This field is encoded as defined in sub-clause 12.33. 

MBMS Session Identity (8 bit field) 

The MBMS Session Identity field is included in the message if the request concerns a specific MBMS session, which is 

known by the mobile station. This field contains the MBMS Session Identity of the concerned MBMS session. 

MSJD Request Indication (1 bit field) 

This field is used by the mobile station to indicate whether an MSJD (and thus the possibility to send feedback) is 
requested by the mobile station. If no MSJD is requested, the mobile station will not be counted by the network for the 
given MBMS session (that does not however prevent the network from addressing and assigning the mobile station an 
MSJD, if available and the network wishes to do so). 

MSJD is not requested 

1 MSJD is requested 



1 1 .2.39 MBMS Assignment (Non-distribution) 

This message is sent on the PCCCH or on the PACCH from the network to (a) mobile station(s) in order to assign the 
radio bearer resources for an MBMS session or to notify the mobile station(s) that a radio bearer for that MBMS session 
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is not established in the cell or to reassign the MBMS Bearer Identity for an MEMS radio bearer or to reassign radio 
resources for an MBMS radio bearer. 

Message type: MBMS ASSIGNMENT (NON-DISTRIBUTION) 

Direction: network to mobile station 

Classification: non-distribution message 

Table 11.2.39.1 : MBMS ASSIGNMENT (NON-DISTRIBUTION) information elements 

< MBMS Assignment Non-distribution message content > ::= 

< PAGE_MODE : bit (2) > 

{ {0 <GlobalTFI :<GlobalTFI IE>> 
I 10 < TLLI / G-RNTI : bit (32) > } 
{ I 1 < Length Indicator of MSJD : bit (2) > 

< MSJD : bit (val (Length Indicator of MS_ID)+1) > 

< Pacl<et Timing Advance : < Packet Timing Advance IE > > 
{ I 1 < ALPHA : bit (4) > 

{0| 1<GAMMA:bit(5)>} 
} 
} 
{ I 1 < TMGI : < TMGI struct > > } 

{ I 1 < MBMS Session Identity : bit (8) > } 

{ 00 ~ Assignment reject. No point-to-multipoint channel is established for the MBMS session. 

< Reject cause: bit (2) > 

{ I 1 < Estimated Session Duration : bit (8) > } 
I 01 -A point-to-multipoint channel is established or reassigned for the MBMS session. 

< MBMS bearer description : < MBMS bearer description struct > > 

< Estimated Session Duration : bit (8) > 

< MBMS In-band Signalling Indicator : < MBMS In-band Signalling Indicator IE > > 

I 1 - The MBMS Bearer Identity is reassigned for the MBMS radio bearer. 

{ I 1 < MBMS Radio Bearer Starting Time : < bit (1 6) > } 

< Length of MBMS Bearer Identity : bit (3) > 

< MBMS Bearer Identity : bit (val (Length of MBMS Bearer Identity)) > 

} 

< padding bits > 

! < Non-distribution part error : bit (*) = < no string > > 
I < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > >; 

< MBMS bearer description struct > :: = 

{ I 1 < MBMS Radio Bearer Starting Time : < bit (16) > } 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

< DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > 

< Length of MBMS Bearer Identity : bit (3) > 

< MBMS Bearer Identity : bit (val (Length of MBMS Bearer Identity)) > 
{ I 1 < EGPRS Window Size : < EGPRS Window Size IE » } 

{ I 1 < TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL : bit (3) > } 

{ I 1 < NPM Transfer Time : bit (5) > } ; 



Table 11.2.39.2: MBMS ASSIGNMENT (NON-DISTRIBUTION) information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Global TFI 

This information element shall always contain the DOWNLINK_TFI field. The most significant bit(s) of the 
DOWNLINK_TFI field denote(s) the MBMS Bearer Identity of the MBMS radio bearer the message relates to. This 
field is defined in sub-clause 12.10. 

TLLI / G-RNTI (32 bit field) 

This field contains the TLLI/G-RNTI of the mobile station. This field is encoded as defined in sub-clause 12.16. 
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MS_ID (1-4 bit field) 

This field addresses the mobile station, identified by the TLLl, receiving the MBMS radio bearer that is described in 
this message and identified by the MBMS Bearer Identity. If the MS_1D parameter is already allocated in the 
IMMEDIATE ASSIGNMENT message (specified in the 3GPP TS 44.018) the network shall omit it in this message. 
This field is defined in sub-clause 12.35. 

Packet Timing Advance 

If the Packet Timing Advance parameter is already allocated in the IMMEDIATE ASSIGNMENT message (specified 
in the 3GPP TS 44.018) the network shall omit it in this message. This information element is defined in sub-clause 
12.12. 

ALPHA (4 bit field) 

If the ALPHA parameter is already allocated in the IMMEDIATE ASSIGNMENT message (specified in the 3GPP TS 
44.018) the network shall omit it in this message. For encoding and description see the Global Power Control 
Parameters IE. 

GAMMA (5 bit field) 

The GAMMA field is the binary representation of the parameter FCH for MS output power control in units of 2 dB, see 
3GPP TS 45.008. If the GAMMA parameter is already allocated in the IMMEDIATE ASSIGNMENT message 
(specified in the 3GPP TS 44.018) the network shall omit it in this message. The GAMMA field is coded according to 
the following table; 

bit 

54321 

00 000 rCH = OdB 

1 rCH = 2 dB 

11110 rCH = 60 dB 

11111 rCH = 62 dB 

TMGI 

This field contains the Temporary Mobile Group Identity of the MBMS service. This field is encoded as defined in sub- 
clause 12.33. 

MBMS Session Identity (8 bit field) 

This field contains the MBMS Session Identity of the concerned MBMS session. 

Reject cause (2 bit field) 

This field indicates whether the mobile station is allowed to perform further MBMS packet accesses for this MBMS 

session. 

00 No radio bearer established - further MBMS packet accesses allowed for this MBMS session in this cell 

01 No radio bearer established - no further MBMS packet accesses allowed for this MBMS session in this cell 

10 No radio bearer established - no further MBMS packet accesses allowed for this MBMS session in this Routing 
Area 

1 1 No radio bearer established - no further MBMS packet accesses allowed for this MBMS session in this PLMN 

Estimated Session Duration (8 bit field) 

This field contains an estimation of either the duration for the concerned MBMS session or, if the MBMS session is 

ongoing, the remaining duration for the concerned MBMS session. This information element is defined in sub-clause 

12.44. 

MBMS In-band Signalling Indicator 

This information element contains the MBMS In-band Signalling Indicator. This information element is defined in sub- 
clause 12.45. 

MBMS Radio Bearer Starting Time (16 bit field) 

This field contains a starting time that indicates the frame number from which the data transfer on the assigned MBMS 
radio bearer may start. The MBMS Radio Bearer Starting Time is encoded as the value part of the type 3 information 
element Starting Time in 3GPP TS 44.018. 
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Frequency Parameters 

If this information element is not present, the same frequency as for the PCCCH or, if the PCCCH is not present in the 
cell, for the CCCH, on which the network sends this message or the IMMEDIATE ASSIGNMENT message including 
the Multiple Blocks Packet Downlink Assignment construction and the Packet Channel Description IE specifying the 
PDCH over which this message is sent (see 3GPP TS 44.018), respectively, shall be used. This information element is 
defined in sub-clause 12.8. 

DOWNLINK_TIMESLOT_ALLOCATION (8 bit field) 
This field is defined in sub-clause 12.18. 

Length of MBMS Bearer Identity (3 bit field) 

This field indicates the length of the MBMS Bearer Identity. Any value from 1 to 5 inclusive is allowed. All other 

values are reserved. 

MBMS Bearer Identity (1-5 bit field) 

This field contains the Bearer identity for the MBMS session. This field is defined in sub-clause 12.34. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL (3 bit field) 

This field, if present, identifies the timeslot where the uplink feedback channel, on which the MBMS DOWNLINK 

ACK/NACK reports shall be sent, is located. 

NPM Transfer Time (5 bit field) 

This field is defined in sub-clause 12.45a. 



1 1 .2.39a MBMS Assignment (Distribution) 



This message is sent on the PCCCH or on the PACCH from the network to mobile stations in order to assign the radio 
bearer resources for an MBMS session or to notify the mobile stations that a radio bearer for that MBMS session is not 
established in the cell. 

Message type: MBMS ASSIGNMENT (DISTRIBUTION) 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.39a.1 : MBMS ASSIGNMENT (DISTRIBUTION) information elements 

< MBMS Assignment Distribution message content > ::= 

< PAGE_MODE : bit (2) > 

{ < TMGI : < TMGI struct > > 

{ I 1 < MBMS Session Identity : bit (8) > } 

{ -- Assignment reject. No point-to-multipoint cliannel is establislied for tlie MBMS session. 

< Reject cause: bit (2) > 

{ I 1 < Estimated Session Duration : bit (8) > } 
I 1 -A point-to-multipoint channel is establislied for the MBMS session. 

< MBMS bearer description : < MBMS bearer description struct > > 

< Estimated Session Duration : bit (8) > 

< MBMS In-band Signalling Indicator : < MBMS In-band Signalling Indicator IE » 

} 

< padding bits > 

! < Distribution part error : bit {*) = < no string > > } ; 

< MBMS bearer description struct > :: = 

{ I 1 < MBMS Radio Bearer Starting Time : < bit (16) > > } 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

< DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > 

< Length of MBMS Bearer Identity : bit (3) > 

< MBMS Bearer Identity : bit (val (Length of MBMS Bearer Identity) ) > 
{ I 1 < EGPRS Window Size : < EGPRS Window Size IE > > } 

{ I 1 < TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL : bit (3) > } 

{ I 1 < NPM Transfer Time : bit (5) > }; 



Table 11. 2.39a.2: MBMS ASSIGNMENT (DISTRIBUTION) information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

TMGI 

This field contains the Temporary Mobile Group Identity of the MBMS service. This field is encoded as defined in sub- 
clause 12.33. 

MBMS Session Identity (8 bit field) 

This field contains the MBMS Session Identity of the concerned MBMS session. 

Reject cause (2 bit field) 

This field indicates whether the mobile station is allowed to perform further MBMS packet accesses for this MBMS 

session. 

00 No radio bearer established - further MBMS packet accesses allowed for this MBMS session in this cell 

01 No radio bearer established - no further MBMS packet accesses allowed for this MBMS session in this cell 

10 No radio bearer established - no further MBMS packet accesses allowed for this MBMS session in this Routing 
Area 

1 1 No radio bearer established - no further MBMS packet accesses allowed for this MBMS session in this PLMN 

Estimated Session Duration (8 bit field) 

This field contains an estimation of the session duration for the concerned MBMS session. This information element is 

defined in sub-clause 12.44. 

MBMS In-band Signalling Indicator 

This information element contains the MBMS In-band Signalling Indicator. This information element is defined in sub- 
clause 12.45. 

MBMS Radio Bearer Starting Time (16 bit field) 

This field contains a starting time that indicates the frame number from which the data transfer on the assigned MBMS 
radio bearer may start. The MBMS Radio Bearer Starting Time is encoded as the value part of the type 3 information 
element Starting Time in 3GPP TS 44.018. 
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Frequency Parameters 

If this information element is not present, the same frequency as for the PCCCH or, if the PCCCH is not present in the 
cell, for the CCCH, on which the network sends this message or the IMMEDIATE ASSIGNMENT message including 
the Multiple Blocks Packet Downlink Assignment construction and the Packet Channel Description IE specifying the 
PDCH over which this message is sent (see 3GPP TS 44.018), respectively, shall be used. This information element is 
defined in sub-clause 12.8. 

DOWNLINK_TIMESLOT_ALLOCATION (8 bit field) 
This field is defined in sub-clause 12.18. 

MBMS Bearer Identity (1-5 bit field) 

This field contains the Bearer identity for the MBMS session. This field is defined in sub-clause 12.34. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL (3 bit field) 

This field, if present, identifies the timeslot where the uplink feedback channel, on which the MBMS DOWNLINK 

ACK/NACK reports shall be sent, is located. 

NPM Transfer Time (5 bit field) 

This field is defined in sub-clause 12.45a. 



1 1 .2.40 MBMS Neighbouring Cell Information 

This optional message is sent by the network on the PACCH to provide details of the bearer allocated to a particular 
MBMS session in a neighbouring cell. This message shall not be segmented across more than one RLC/MAC control 
block. If not all information fits into one instance of the MBMS NEIGHBOURING CELL INFORMATION message, 
the information can be distributed over more than one instance of the message. 

Message type: MBMS NEIGHBOURING CELL INFORMATION 

Direction: network to mobile station 

Classification: distribution message 
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Table 11.2.40.1: MBMS Neighbouring Cell Information information elements 

< MBMS Neighbouring Cell Information message content > ::= 

< PAGE_MODE : bit (2) > 

{ 1 < NEIGHBOUR_CELLJNDEX : bit (7) > 
{ I 1 < BSIC : bit (6) > } 

< MBMS_PTM_CHANGE_MARK : bit (2) > 

{1 

< Length of MBMS Bearer Identity : bit (3) > 

< MBMS Bearer Identity : bit (val (Length of MBMS Bearer Identity)) > 

< Absence cause: bit (2) > 

} ** -- End of list of MBf\/JS bearers for which no p-t-m channel description is given In the neighbour cell 

{ 1 < MBMS Frequency List : < MBMS Frequency List struct > > } **0 

{1 

< MBMS p-t-m Frequency Parameters : < MBMS p-t-m Frequency Parameters struct > > 

< DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > - default value 

{1 

< Length of Serving MBMS Bearer Identity : bit (3) > 

< Serving MBMS Bearer Identity : bit (val (Length of Serving MBMS Bearer Identity)) > 

< Length of Neighbour MBMS Bearer Identity : bit (3) > 

< Neighbour MBMS Bearer Identity : bit (val (Length of Neighbour MBMS Bearer Identity)) > 
{ I 1 < EGPRS Window Size : < EGPRS Window Size IE » } 

{ I 1 < DOWNLINK_TIMESLOT_ALLOCATION : bit (8) > } - specific value 

{ I 1 < TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL : bit (3) > } 
{ I 1 < MBMS Radio Bearer Starting Time : < bit (1 6) > > } 

< MBMS In-band Signalling Indicator : < MBMS In-band Signalling Indicator IE » 
{ I 1 < NPM Transfer Time : bit (5) > } 

} ** - End of list of MBMS bearer descriptions sharing the same PDCH (frequency parameters) 
} ** - End of list of PDCHs for this cell 

{ I 1 < PBCCH information : < PBCCH information struct > > } } ** - End of list of neighbouring 

cells 

< padding bits > 

! < Distribution part error : bit (*) = < no string > > ; 

< PBCCH information struct > :: = 

< Pb : bit (4) > 

< TSC : bit (3) > 

< TN : bit (3) > 

{ 00 - non-hopping PBCCH on BCCH carrier 

I 01 < ARFCN : bit (1 0) > - non-hopping PBCCH 

I 1 - hopping PBCCH, frequency parameters from an MBMS bearer description for this cell 

< Length of Neighbour MBMS Bearer Identity : bit (3) > 

< Neighbour MBMS Bearer Identity : bit (val (Length of Neighbour MBMS Bearer Identity)) > } ; 

< MBMS Frequency List struct > :: = 

< FREQ_LIST_NUMBER : bit (2) > 

< Length of Frequency List contents : bit (4) > 

< Frequency List contents : octet (val(Length of Frequency List contents) -h 3) > ; 

< MBMS p-t-m Frequency Parameters struct > :: = 

< TSC : bit (3) > 

{0 < ARFCN :bit(10> 
I 1 < MAIO : bit (6) > 

< HSN : bit (6) > 

< FREQ_LIST_NUMBER : bit (2) > } ; 



Table 11.2.40.2: MBMS Neighbouring Cell Information information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20 and gives the PAGE_MODE parameter valid in the serving cell. 
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NEIGHBOUR_CELL_INDEX (7 bit field) 

This information element is the index within the GSM Neighbour Cell list (defined in sub-clause 5.6.3.2) of the cell for 

which information is provided. 

If the mobile station has not completed the construction of the GSM Neighbour Cell list (i.e. before the MS has 
acquired the complete GSM Neighbour Cell list from the BCCH messages, in case the PBCCH is not allocated in the 
cell), it shall not disregard this message but store the information contained in it. 

BSIC (6 bit field) 

This optional field is needed to identify the neighbour cell in case the GSM Neighbour Cell list is only a frequency list, 
see 3GPP TS 44.060 sub-clause 5.6.3.2. 

MBMS_PTM_CHANGE_MARK (2 bit field) 

This field contains the change mark value for the information given for a specific neighbouring cell. This information is 
used to combine information from multiple instances of the MBMS Neighbouring Cell Information message. 

MEMS Bearer Identity (1-5 bit field) 

This field contains the Bearer identity for the MBMS session. This field is defined in sub-clause 12.34. 

Absence cause (2 bit field) 

This field indicates why the description of the MBMS bearer for the neighbour cell is not provided in the message. 

00 Neighbour cell not in the service area for the MBMS service associated with this Bearer identifier 

01 No p-t-m bearer established in the neighbour cell for the MBMS service associated with this Bearer identifier 

10 p-t-m bearer established in the neighbour cell for this MBMS service, but the description cannot be provided 

1 1 No information available for the MBMS service associated with this bearer identifier 

Serving MBMS Bearer Identity (1-5 bit field) 

This field contains the Bearer identity used by the MBMS session in the serving cell. This field is encoded as the 

MBMS Bearer Identity IE defined in sub-clause 12.34. 

Neighbour MBMS Bearer Identity (1-5 bit field) 

This field contains the Bearer identity used by the MBMS session in the neighbour cell. This field is encoded as the 

MBMS Bearer Identity IE defined in sub-clause 12.34. 

MBMS p-t-m Frequency Parameters 

This information provides a description of a hopping or non-hopping radio frequency channel. In case hopping 
frequency channel is decribed, a reference to a specified MBMS Frequency List shall be provided. If MBMS Frequency 
List has not been received by the MS, it shall store this information for possible later use in case such MBMS 
Frequency List is received. 

TSC (3 bit field) 

This field is the binary representation of the training sequence code, see 3GPP TS 45.002. Range; to 7. 

ARFCN (10 bit field) 

This field is the binary representation of the absolute radio frequency channel number (ARFCN) defined in 

3GPP TS 45.005. Range to 1023. 

MAIO (6 bit field) 

This field is the binary representation of the mobile allocation index offset (MAIO), see 3GPP TS 45.002. Range to 

63. 

HSN (6 bit field) 

This field is the binary representation of the hopping sequence number, see 3GPP TS 45.002. Range: to 63. 

FREQ_LIST_NUMBER (2 bit field) 

This field is the binary identification of a MBMS Frequency List provided by an instance of this message, or the binary 

reference to such.Range: to 3. 

MBMS Frequency List 

This information contains a set of radio frequency channels. This list shall be identified by the 
FREQ_LIST_NUMBER field. 
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Frequency List contents (variable length octet string) 

This variable length octet string is the representation of a set of radio frequency channels defining a GPRS mobile 
allocation. The encoding of the octet string is defined by the value part of the type 4 information element Frequency 
List, defined in 3GPP TS 44.018. The allowed formats of the Frequency List information element are the bit map 0, 
1024 range, 512 range, 256 range, 128 range and variable bit map formats. 

DOWNLINK_TIMESLOT_ALLOCATION (8 bit field) 

This information element describes which timeslots are allocated to the MBMS bearer in the neighbouring cell. This 

field is encoded as the Timeslot Allocation field defined in sub-clause 12.18. 

The field following the Frequency Parameters information element shall refer to all the MBMS bearers described in the 
subsequent loop (default value). If this field is provided for a particular MBMS bearer, it refers only to that MBMS 
bearer (this specific value overrides the default value). Every MBMS bearer shall be assigned either the default value or 
a specific value. 

TIMESLOT_ALLOCATION_UPLINK_FEEDBACK_CHANNEL (3 bit field) 

This field indicates the timeslot used for the uplink feedback channel in the neighbour cell. This field is coded as the 

binary representation of the timeslot number. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

MBMS Radio Bearer Starting Time (16 bit field) 

This field contains a starting time that indicates the frame number from which the data transfer on the assigned MBMS 
radio bearer may start. The MBMS Radio Bearer Starting Time is encoded as the value part of the type 3 information 
element Starting Time in 3GPP TS 44.018. 

MBMS In-band Signalling Indicator 

This information element contains the MBMS In-band Signalling Indicator. This information element is defined in sub- 
clause 12.45. 

PBCCH information 

This information, if present, describes the PBCCH location in the target cell. In case PBCCH is allocated in the target 
cell and can be described with this encoding, this information shall be included in the message. 

NPM Transfer Time (5 bit field) 

This field is defined in sub-clause 12.45a. 



11.2.41 MBMS MSJD Assignment 

This message is sent on the PACCH by the network to the mobile station to assign an MSJD and to provide the timing 
advance parameters to the mobile station in case of an MBMS radio bearer with an assigned uplink feedback channel. 
The message can also be used to reassign or delete the MSJD assigned to the mobile station. 

Message type: MBMS MSJD ASSIGNMENT 

Direction: network to mobile station 

Classification: non-distribution message 
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Table 11.2.41.1: MBMS MSJD ASSIGNMENT information elements 

< MBMS MS_ID Assignment message content > ::= 
< PAGE_MODE : bit (2) > 
{ { < Global TFI : < Global TFI IE > > 
I 10 < TLLI / G-RNTI : bit (32) > } 
{ -- MS_ID is assigned the first time. 

< Length of MBMS Bearer Identity : bit (3) > 

< MBMS Bearer Identity : bit (val (Length of MBMS Bearer Identity)) > 

< MSJD : bit (5 - val (Length of MBMS Bearer Identity)) > 

< Packet Timing Advance : < Packet Timing Advance IE > > 

{ I 1 < ALPHA : bit (4) > 

{0| 1<GAMMA:bit(5)>} 

} 
I 1 -- MSJD is reassigned. 

< Current MSJD Expiry Time : bit (16) > 

{ -- MS_ID is not redefined. 

I 1 -- MS_ID is redefined. 

< Length Indicator of MS_ID : bit (2) > 

< MSJD : bit (val (Length Indicator of MSJD) + 1) > } 

{ I 1 < Packet Timing Advance : < Packet Timing Advance IE > > } 

{ I 1 < ALPHA : bit (4) > 

{0| 1<GAMMA:bit(5)>} 

} 
} 

< padding bits > 

! < Non-distribution part error : bit (*) = < no string > > } 
! < Address information part error : bit (*) = < no string > > } 
! < Distribution part error : bit (*) = < no string > > ; 



Table 11.2.41.2: lUIBMS MSJD ASSIGNMENT information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Global TFI 

This information element shall always contain the DOWNLINK_TFI field. The most significant bit(s) of the 
DOWNLINK_TFI field denote(s) the MBMS Bearer Identity of the MBMS radio bearer the message relates to and the 
remaining least significant bit(s) denote(s) the MSJD addressing the mobile station the message relates to. This field is 
defined in sub-clause 12.10. 

TLLI / G-RNTI (32 bit field) 

This field contains the TLLI/G-RNTI of the mobile station. This field is encoded as defined in sub-clause 12.16. 

MBMS Bearer Identity (1-5 bit field) 

This field identifies the MBMS radio bearer this message relates to and is defined in sub-clause 12.34. 

MSJD (1-4 bit field) 

This field assigns an identifier to the mobile station, identified by the TLLI, on the MBMS radio bearer identified by the 
MBMS Bearer Identity, and can also be used to reassign the identifier assigned to the mobile station. This field is 
defined in sub-clause 12.35. 

Packet Timing Advance 

This information element is defined in sub-clause 12.12. 

ALPHA (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 

GAMMA (5 bit field) 

The GAMMA field is the binary representation of the parameter FCH for MS output power control in units of 2 dB, see 

3GPP TS 45.008. The GAMMA field is coded according to the following table: 

bit 

5432 1 
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000 rCH = OdB 
1 rCH = 2 dB 

11110 rCH = 60 dB 

11111 rCH = 62 dB 

Current MS_ID Expiry Time 

This field contains an expiry time that indicates the frame number during which the mobile station shall consider the 
current MS_ID as released and, if a new MS_ID is assigned, the new MS_ID as valid. This information element is 
encoded as the value part of the Starting Time information element specified in 3GPP TS 44.018. 



1 1 .2.42 Packet MBMS Announcement 

This message is sent on PACCH by the network to notify all MBMS mobile stations listening to that PDCH that an 
MBMS Service is commencing. 

Message type: PACKET MBMS ANNOUNCEMENT 

Direction: network to mobile station 

Classification: distribution message 

Table 11.2.42.1: PACKET MBMS ANNOUNCEMENT information elements 

< PACKET MBMS ANNOUNCEMENT message content > ::= 

< PAGE_MODE : bit (2) > 
<TMGI :<TMGI IE > > 

{ I 1 < MBMS Session Identity : bit (8) > } 

{ -- counting is off 

{ I 1 < MBMS p-t-m channel description : < MBMS p-t-m channel description struct > > } 
I 1 -- counting is on 

{ I 1 < MPRACH description : < MPRACH description struct > > } 

} 
{ I 1 < RESTRICTION_TIMER : bit (4) > } 

< padding bits > } // -- truncation at end of message aliowed, bits '0' assumed 
! < Distribution part error : bit (*) = < no string > > ; 

< MBMS p-t-m channel description struct > :: = 

< Estimated Session Duration : bit (8) > 

{ I 1 < MBMS Radio Bearer Starting Time : < Starting Frame Number Description IE > > } 
{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

< DL_TIMESLOT_ALLOCATION : bit (8) > 

< Length of MBMS Bearer Identity : bit (3) > 

< MBMS Bearer Identity : bit (val (Length of MBMS Bearer Identity)) > 
{ I 1 < EGPRS Window Size : < EGPRS Window Size IE » } 

{ I 1 < NPM Transfer Time : bit (5) > }; 

< MPRACH description struct > :: = 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 

< MPRACH_TIMESLOT : bit (3) > 

< USF : bit (3) > 

{0 --no l\/IPRACH access parameters present 

I 1 - l\/IPRACH access parameters present 

< MPRACH Control Parameters : < MPRACH Control Parameters IE > > } ; 



Table 11.2.42.2: PACKET MBMS ANNOUNCEMENT information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 
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TMGI IE 

This field contains the Temporary Mobile Group Identity of the MBMS service that the MBMS Notification concerns. 
This field is encoded as defined in sub-clause 12.33. 

MBMS Session Identity (8 bit field) 

This field contains the MBMS Session Identity of the concerned MBMS session (see TS 23.003). 

Estimated Session Duration (8 bit field) 

This field contains an estimation of the session duration for the concerned MBMS session. This information element is 

defined in sub-clause 12.44. 

MBMS Data Transfer Starting Time 

The MBMS Data Transfer Starting Time field contains a starting time that indicates the frame number during which the 
data transfer on the assigned MBMS radio bearer may start. This information element is encoded as the Starting Frame 
Number Description IE. See sub-clause 12.21 

Frequency Parameters 

If this information element is not present, the same frequency as for the PCCCH shall be used. This information 
element is defined in sub-clause 12.8. 

DL_TIMESLOT_ALLOCATION (8 bit field) 
This field is defined in sub-clause 12.18. 

MBMS Bearer Identity (1-5 bit field) 

This field assigns a TFI value, or a subset of a TFI value, which identifies the MBMS radio bearer that is described. In 
case only a subset of a TFI value is assigned for the MBMS radio bearer, that subset corresponds to the most significant 
bit(s) of the TFI field. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

MPRACH_TIMESLOT (3 bit field) 

This field identifies the timeslot number of the PDCH where the MPRACH is located. 

USE (3 bit field) 

This field identifies the USF value that identifies the MPRACH on the defined PDCH. 

MPRACH Control Parameters 

This information element, if present, defines the access control parameters to be used on the MPRACH. This 
information element is defined in sub-clause 12.41. 

RESTRICTION_TIMER 

This field indicates the maximum reaction time to the PACKET MBMS ANNOUNCEMENT in seconds for mobile 
station, before the information contained in the PACKET MBMS ANNOUNCEMENT expires. 



Bit 




4321 




0000 


10 


0001 


20 


0010 


30 


1110 


150 


1111 


160 



NPM Transfer Time (5 bit field) 

This field is defined in sub-clause 12.45a. 



1 1 .2.43 PS Handover Command 

This message is sent on the PACCH by the network to the mobile station to command the mobile station to leave the 
current cell and change to a new cell. The mobile station shall acknowledge this message according to sub-clause 
8.10.4. This message can be sent using Extended RLC/MAC control segmentation (see sub-clause 9.1.12a). 
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Message type: PS HANDOVER COMMAND 
Direction: network to mobile station 

Classification: non-distribution message 

Table 11.2.43.1: PS HANDOVER COMMAND information elements 

< PS Handover Command message content > ::= 
< PAGE_MODE : bit (2) > 
{ < Global TFI : < Global TFI IE > > 

< CONTAINERJD : bit(2) > 

{00 < PS Handover to A/Gb Mode Payload : 

{GO < PS Handover RR Info: < PS Handover Radio Resources IE > > 

! < PS Handover RR Info Error : { 01 | 10 | 11 } bit (*) = <no string> > } - Extended for future changes 

{ I 1 < NAS Container for PS Handover IE > } 

I 01 < PS Handover to UTRAN Payload : 
< RRC Container IE>>} 

< padding bits > 

! < Non-distribution part error : bit (*) = < no string > > 
I < Address information part error : bit {*) = < no string > > } 
I < Distribution part error : bit (*) = < no string > > ; 



Table 11.2.43.2: PS HANDOVER COMMAND information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

CONTAINERJD (2 bit field) 

This field contains the identity of the neighbour cell system information container previously sent in the PACKET 

NEIGHBOUR CELL DATA messages (see sub-clause 8.10.2). 

Range to 3. 

PS Handover to A/Gb Mode Payload 

This information element contains the information needed by the mobile station when performing PS Handover to A/Gb 
mode. It consists of the PS Handover Radio Resources IE (see sub-clause 12.42) and optionally the NAS Container for 
PS Handover IE (see sub-clause 12.43). 

PS Handover to UTRAN Payload 

This information element contains a HANDOVER TO UTRAN COMMAND message (as defined in 3GPP TS 25.331) 
containing the information needed by the mobile station when performing PS Handover to UTRAN. This information 
element is defined in sub-clause 12.45b. 



1 1 .2.44 PS Handover Access 

This message is sent by the mobile station to the network to make the network aware that the mobile station has left the 
old cell and arrived in the new cell. The message is sent four times using either the 8-bit or 1 1-bit access burst format on 
the PACCH associated with an uplink TBF allocated in the PS Handover Command message as described in sub-clause 
8.10.4. The mobile station shall use the format indicated by the System Information parameter 

ACCESS_BURST_TYPE applicable to the target cell. Each message is coded as shown in table 11.2.42.1. The order of 
bit transmission is defined in 3GPP TS 44.004. The numbering, assembling and field mapping conventions defined for 
RLC/MAC control blocks in sub-clause 10.0b shall apply. 

Message type: PS HANDOVER ACCESS 

Direction: mobile station to network 
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Table 11.2.44.1: PS HANDOVER ACCESS information elements 

< PS Handover Access message content 8 bit message > ::= -- 8-bit access burst format 

< Handover Reference : bit (8) >; 

< PS Handover Access message content 1 1 bit message > ::= -- 1 1-bit access burst format 

< Handover Reference : bit (8) > 

< spare : bit (3) > ; 

Table 11.2.44.2 : PS HANDOVER ACCESS information element details 

Handover Reference (8 bit field) 

This information field identifies the mobile station in the new cell. The semantics of this field is defined in 

3GPPTS 44.018. 

spare (3 bit field) 

These bits are reserved for future use and shall be set to '000' in this release. 

1 1 .2.45 Packet Physical Information {A/Gb mode only) 

This message is sent on PACCH by the network to the mobile station during a handover procedure as specified in sub- 
clause 8.10 to indicate a valid timing advance to the mobile station. 

Message type: PACKET PHYSICAL INFORMATION 

Direction: network to mobile station 

Classification: non-distribution message 

Table 11.2.45.1: PACKET PHYSICAL INFORIVIATION information elements 

< Pacl<et Physical information message content > ::= - RLC/MAC control block format 

< PAGE_MODE : bit (2) > 

< Global TFI : < Global IF! IE > > 

< TIMING_ADVANCE_VALUE : bit (8) > 

< padding bits >; - truncation at end of message allowed, bits '0' assumed 

Table 11.2.45.2: PACKET PHYSICAL INFORMATION information element details 

PAGE_MODE (2 bit field) 

This field is defined in sub-clause 12.20. 

Global TFI 

This information element contains the TFI of the mobile station's downlink TBF or uplink TBF. This field is defined in 

sub-clause 12.10. 

TIMING_ADVANCE_VALUE (8 bit field) 

This field is coded as the timing advance value field defined in 3GPP TS 44.018. 
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12 Information element coding 

12.1 Overview 

Information elements used within the context of only one RLC/MAC control message are defined in clause 1 1 . All 
other information elements are defined within the present sub-clause. 

12.2 (void) 

1 2.3 Ack/Nack Description 

The Ack/Nack Description information element contains the RLC parameters used to acknowledge or negatively 
acknowledge a group of RLC data blocks. 

Table 12.3.1 : Ack/Nack Description information elements 

< Ack/Nack Description IE > ::= 

< FINAL_ACKJNDICATION : bit (1) > 

< STARTING_SEQUENCE_NUMBER : bit (7) > 

< RECEIVED_BLOCK_BITMAP : bit (64) > ; 

Table 12.3.2: Ack/Nack Description information element details 

FINAL_ACK_INDICATION (1 bit field) 

This field indicates whether the entire TBF is being acknowledged. If, in case the uplink TBF is operating in non- 
extended uplink TBF mode, the entire TBF is being acknowledged, the SSN and RBB fields contain no information and 
shall be ignored. When acknowledging the entire TBF in extended uplink TBF mode the SSN and RBB fields shall be 
interpreted. 

retransmission are requested and the TBF is incomplete 

1 no retransmissions are requested and this message indicates acknowledgement of all RLC data in the TBF 

STARTING_SEQUENCE_NUMBER (SSN) (7 bit field) 

The SSN contains the value of V(R) when this information element was transmitted. This field is encoded as the binary 

representation of V(R). 

Range to 127 

RECEIVE_BLOCK_BITMAP (RBB) (64 bit field) 

The RBB is a bitmap representing Block Sequence Numbers. The bitmap is indexed relative to SSN as follows; 

BSN = (SSN - bit_number) modulo 128, for bit_number = 1 to 64. 

The BSN values represented range from (SSN - 1) mod 128 to (SSN - 64) mod 128. 

The value of each bit is encoded as: 

Negative acknowledgement of the RLC data block with BSN = (SSN - bit_number) mod 128 

1 Positive acknowledgement of the RLC data block with BSN = (SSN - bit_number) mod 128 

Mapping of the bitmap is defined on sub-clause 1 1 . 



12.3.1 EGPRS Ack/Nack Description 

The Ack/Nack Description information element contains the RLC parameters used to acknowledge or negatively 
acknowledge a group of RLC data blocks. The number of bits available for the bitmap depends on the inclusion or 
exclusion of other information elements in the used message. 
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Table 12.3.1.1: EGPRS Ack/Nack Description information elements 

< EGPRS Ack/Nack Description IE > ::= 

< EGPRS Ack/Nack Description struct > -- This IE fills rest of message 

1 1 < Length L : bit (8) > -- Value part of this IE is of length L 

{ < bit (val(Length L)) > & < EGPRS Ack/Nack Description struct > } ; 

< EGPRS Ack/Nack Description struct > ::= 

< FINAL_ACKJNDICATION : bit (1) > 

< BEGINNING_OF_WINDOW : bit (1) > 

< END_OF_WINDOW : bit (1) > 

< STARTING_SEQUENCE_NUMBER : bit (1 1) > 

{ I 1 < COMPRESSED_BITMAP_LENGTH: bit (7) > 

< COMPRESSED_BITMAP_STARTING_COLOR_CODE: bit (1) > 

< COMPRESSED_RECEIVED_BLOCK_BITMAP : 

bit (val(COMPRESSED_BITMAP_LENGTH)) > } 

< UNCOMPRESSED RECEIVED BLOCK BITMAP: bit" > ; 



Table 12.3.1.2: EGPRS Ack/Nack Description information element details 

LENGTH L (8 bit field) 

Range 15 to 255 

This field represents the length of the value part (i.e. the EGPRS Ack/Nack Description struct) of this information 

element. If this field is not included, this information element fills the remaining part of the message. 

FINAL_ACK_INDICATION (1 bit field) 

This field indicates whether the entire TBF is being acknowledged. If, in case the uplink TBF is operating in non- 
extended uplink TBF mode, the entire TBF is being acknowledged, the SSN, CRBB and URBB fields contain no 
information and shall be ignored. When acknowledging the entire TBF in extended uplink TBF mode, the SSN, CRBB 
and URBB fields shall be interpreted if present. 

retransmissions are requested and the TBF is incomplete. 

1 no retransmissions are requested and this message indicates acknowledgement of all RLC data in the TBF. 

BEGINNING_OF_WINDOW (BOW, 1 bit field) 

This bit indicates if the Ack/Nack bitmap starts at the beginning of the window. 

SSN not equal to (V(Q)+l) mod 2048. 

1 SSN = (y('0+l) mod 2048 

END_OF_WINDOW (EOW, 1 bit field) 

This bit indicates if the end of the receiver window is included in the bitmap(s). 

[V(R) - 1] modulo SNS is not included in the bitmap. 

1 [V(R) - 1] modulo SNS is included in the bitmap. 

STARTING_SEQUENCE_NUMBER (SSN) (11 bit field) 

Range to 2047 

The SSN indicates the Block Sequence Number of the first RLC block for which the Ack/Nack receipt status is 

indicated within the bitmap. The SSN is determined using S/P, PBSN and V(Q). 

COMPRESSED_BITMAP_LENGTH (Lc) (7 bit field) 

Range to 127 

This field represents the length of the compressed bitmap. Compression is carried out using T.4 run length coding. 

COMPRESSED_BITMAP_STARTING_COLOR_CODE (1 bit field) 

This bit indicates if the first code word in the compressed bitmap (i.e. CRBB) represents a run length of ones or a run 

length of zeros. 

First code word in CRBB represents run length of zeros. 

1 First code word in CRBB represents run length of ones. 
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COMPRESSED_RECEIVE_BLOCK_BITMAP (CRBB) (Lc bit field) 

The CRBB is a compressed bitmap. Compression is carried out starting at SSN using modified T.4 run length coding. 
The number of bits (Lc) available for Ack/Nack Description depends on the inclusion of other information elements in 
the used message. 

The packing order of the CRBB shall be such that the codeword (or pair of make up/terminating codewords) 
corresponding to the run including the SSN starts at the most significant bit of the CRBB, and codewords (or pairs of 
make-up/terminating codewords) corresponding to runs including higher and successively increasing sequence numbers 
are placed in bits of successively decreasing significance. 

NOTE: The URBB is packed in the opposite order. 

UNCOMPRESSED_RECEIVE_BLOCK_BITMAP (URBB) (Lu bit field) 

The URBB is an uncompressed bitmap, which fills the remainder of this information element upto L bits, where L is the 

number of bits available for the EGPRS Ack/Nack description struct. The URBB field length, Lu, is determined by: 

Lu = L-Lc-23, when the compressed received block bitmap is included, or by 
Lu = L-15, when the compressed received block bitmap is not included: 

The bits in URBB, denoted here by index i, are numbered from i=l (lowest order value) to i=Lu (highest order value). 
The value of each bit in the bitmap is encoded as following: 

Negative acknowledgement of the RLC data block with BSN = (ESN_CRBB + i) modulo SNS, and 

1 Positive acknowledgement of the RLC data block with BSN = (ESN_CRBB + i) modulo SNS, where 
ESN_CRBB is the ending block sequence number of CRBB and, if no CRBB is included, 
ESN_CRBB = (SSN - 1) modulo SNS. 



1 2.3.2 FLO Ack/Nack Description 

The FLO Ack/Nack Description information element contains the RLC parameters used to acknowledge or negatively 
acknowledge a group of RLC data blocks. 

Table 12.3.2.1: FLO Ack/Nack Description information elements 

< FLO Ack/Nack Description IE > ::= 

< FLO Ack/Nack Description struct > ; 

< FLO Ack/Nack Description struct > ::= 

< BEGINNING_OF_WINDOW : bit (1) > 

< END_OF_WINDOW : bit (1) > 

< STARTING_SEQUENCE_NUMBER : bit (10) > 

{ < COMPRESSED_BITMAP_LENGTH: bit (7) > 

< COMPRESSED_BITMAP_STARTING_COLOR_CODE: bit (1) > 

< COMPRESSED_RECEIVED_BLOCK_BITMAP: bit (val(COMPRESSED_BITMAP_LENGTH)) > 
I 1 < UNCOMPRESSED_RECEIVED_BLOCK_BITMAP: bit" > } ; 
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Table 12.3.1.2: Ack/Nack Description information element details 

BEGINNING_OF_WINDOW (BOW, 1 bit field) 

This bit indicates whether the status of the RLC data block corresponding to V(Q) i.e. '0' is included in the reported 

bitmap or not. 

the reported bitmap does not cover V(Q) 

1 the reported bitmap covers V(Q) 

END_OF_WINDOW (EOW, 1 bit field) 

This bit indicates whether the end of the receiver window is included in the reported bitmap or not. 

[V(R) - 1] modulo SNS is not included in the reported bitmap. 

1 [V(R) - 1] modulo SNS is included in the reported bitmap. 

STARTING_SEQUENCE_NUMBER (SSN) (10 bit field) 

Range to 1023 

The SSN indicates the Block Sequence Number of the last RLC block for which the Ack/Nack receipt status is 

indicated within the reported bitmap. The SSN is determined as specified in 3GPP TS 44.160. 

COMPRESSED_BITMAP_LENGTH (Lc) (7 bit field) 

Range to 127 

This field represents the length of the compressed bitmap. Compression is carried out using T.4 run length coding. 

COMPRESSED_BITMAP_STARTING_COLOR_CODE (1 bit field) 

This bit indicates if the first code word in the compressed bitmap (i.e. CRBB) represents a run length of ones or a run 

length of zeros. 

First code word in CRBB represents run length of zeros. 

1 First code word in CRBB represents run length of ones. 

COMPRESSED_RECEIVE_BLOCK_BITMAP (CRBB) (Lc bit field) 

The CRBB is a compressed bitmap. Compression is carried out starting at SSN-1 and going in decreasing order of the 

BSN, using modified T.4 run length coding. 

The packing order of the CRBB shall be such that the codeword (or pair of make up/terminating codewords) 
corresponding to the run including the SSN-1 starts at the least significant bit of the CRBB, and codewords (or pairs of 
make-up/terminating codewords) corresponding to runs including lowed and successively decreasing sequence numbers 
are placed in bits of successively increasing significance. 

UNCOMPRESSED_RECEIVE_BLOCK_BITMAP (URBB) (Lu bit field) 
The URBB is an uncompressed bitmap of length Lu bits. 

The bits in URBB, denoted here by index i, are numbered from i=l (highest order value i.e. corresponding to SSN-1) to 
i=Lu (lowest order value). The value of each bit in the bitmap is encoded as following: 

Negative acknowledgement of the RLC data block with BSN = (SSN - 1 - i) modulo SNS, and 

1 Positive acknowledgement of the RLC data block with BSN = (SSN - 1 - i) modulo SNS 



12.4 (void) 

12.5 EGPRS 

1 2.5.1 EGPRS Channel Quality Report 

EGPRS Channel Quality Report Information Element. 
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Table 12.5.1.1 : EGPRS Channel Quality Report Information elements 

< EGPRS Channel Quality Report > ::= 

< EGPRS BEP Link Quality Measurements : < EGPRS BEP Link Quality IVIeasurements IE» 

< C_VALUE : bit (6) > 

< EGPRS Timeslot Link Quality Measurements : <EGPRS Timeslot Link Quality Measurements IE » ; 

Table 12.5.1.2 : EGPRS Channel Quality Report Information Elements details 

EGPRS BEP Link Quality Measurements IE 

This information element is defined in sub-clause 12.5.3. These fields are transferred according to the setting of the 
ES/P field, see sub-clause 9.1.8.2.1. 

EGPRS Timeslot Link Quality Measurements 

This information element is defined in sub-clause 12.5.4. 

C_VALUE (6 bits) 

This field contains the value of the C parameter calculated by the mobile station (see 3GPP TS 45.008). This field is 

encoded as the binary representation of the C value parameter value defined in 3GPP TS 45.008. 

Range to 63 



1 2.5.2 EGPRS Window Size 

This information element defines the window size to be used in an EGPRS TBF. The network sets the window size 
according to the number of timeslots allocated in the direction of the TBF. 

If RLC acknowledged mode or RLC unacknowledged mode are signalled in the assignment/reconfiguration message, 
the window size is defined according to Table 12.5.2.1 below. 
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Table 12.5.2.1 : EGPRS Window Size Information Elements details for RLC (un)acknowledged mode 



bit 
54321 


Value of EGPRS 
window size 


Comment 


00000 


64 




0000 1 


96 




00010 


128 




00011 


160 




00100 


192 


(maximum window size for a 1 timeslot TBF) 


0010 1 


224 




00110 


256 


(maximum window size for a 2 timeslot TBF) 


00111 


288 




1000 


320 




1001 


352 




1010 


384 


(maximum window size for a 3 timeslot TBF) 


1011 


416 




1100 


448 




110 1 


480 




1110 


512 


(maximum window size for a 4 timeslot TBF) 


1111 


544 




10000 


576 




1000 1 


608 




10010 


640 


(maximum window size for a 5 timeslot TBF) 


10011 


672 




10100 


704 




1010 1 


736 




10110 


768 


(maximum window size for a 6 timeslot TBF) 


10111 


800 




11000 


832 




11001 


864 




11010 


896 


(maximum window size for a 7 timeslot TBF) 


11011 


928 




11100 


960 




1110 1 


992 




11110 


1024 


(maximum window size for an 8 timeslot TBF) 


11111 


Reserved 





If an MBMS bearer is allocated RLC non-persistent mode shall be used. For this case the window size is defined 
according to Table 12.5.2.2 below. 
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Table 12.5.2.2: EGPRS Window Size Information Elements details for RLC non-persistent mode 



bit 
54321 


Value of EGPRS 
window size 


Comment 


00000 


1 




0000 1 


2 




00010 


4 




00011 


6 




00100 


8 




0010 1 


10 




00110 


12 




00111 


16 




1000 


20 




1001 


24 




1010 


32 




1011 


40 




1100 


48 




110 1 


56 




1110 


64 




1111 


80 




10000 


96 




1000 1 


112 




10010 


128 




10011 


160 




10100 


192 


(maximum window size for a 1 timeslot TBF) 


1010 1 


256 


(maximum window size for a 2 timeslot TBF) 


10110 


320 




10111 


384 


(maximum window size for a 3 timeslot TBF) 


11000 


448 




11001 


512 


(maximum window size for a 4 timeslot TBF) 


11010 


576 




11011 


640 


(maximum window size for a 5 timeslot TBF) 


11100 


768 


(maximum window size for a 6 timeslot TBF) 


1110 1 


896 


(maximum window size for a 7 timeslot TBF) 


11110 


1024 


(maximum window size for a 8 timeslot TBF) 


11111 


Reserved 





1 2.5.3 EGPRS BEP Link Quality Measurements IE 

The EGPRS BEP Link Quality measurements IE. 

Table 12.5.3.1 : EGPRS BEP Link Quality Information elements 

<EGPRS BEP Link Quality Measurements IE> ::= 
{ I 1 < GMSK_I\/IEAN_BEP : bit (5) > 

< GMSK_CV_BEP : bit (3) >} 
{ I 1 < 8PSK_MEAN_BEP : bit (5) > 
< 8PSK_CV_BEP : bit (3) > }; 



Table 12.5.3.2 : EGPRS BEP Link Quality Information Elements details 

GMSK_MEAN_BEP (5 bit field) 

This field contains the mean value of the Bit Error Probability of the channel averaged over all time slots in the TBF for 

OMSK, refer to 3GPP TS 45.008. 

8PSK_MEAN_BEP (5 bit field) 

This field contains the mean value of the Bit Error Probability of the channel averaged over all time slots in the TBF for 

8 PSK, refer to 3GPP TS 45.008. 

GMSK_CV_BEP (3 bit field) 

This field contains the variation co-efficient for the Bit Error Probability averaged over all time slots of the TBF for 

OMSK, refer to 3GPP TS 45.008. 
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8PSK_CV_BEP (3 bit field) 

This field contains the variation co-efficient for the Bit Error Probability averaged over all time slots of the TBF for 8 

PSK, refer to 3GPP TS 45.008. 



1 2.5.4 EGPRS Timeslot Link Quality Measurements IE 

The EGPRS Timeslot Link Quality measurements IE. Information to be included within this IE is indicated by the 
LINK_QUALITY_MEASUREMENT_MODE field within the Packet Downlink Assignment and Packet Timeslot 
Reconfigure messages. 

Table 12.5.4.1: EGPRS Timeslot Link Quality Measurements Information elements 



<EGPRS Timeslot Link Quality Measurements IE> ::= 


{0| 1< 


BEP_MEASUREMENTS : BEP Measurement Report Struct >} 


{ 1 < INTERFERENCE_MEASUREMENTS : Interference Measurement Report Struct >}; 


<BEP 


Measurement Report Struct > ::= 


{0 


1 { <GMSK MEAN BEP TNO : bit (4) > 




1 1 < 8PSK MEAN BEP TNO : bit (4) >}} 


{0 


1 { <GMSK MEAN BEP TNI : bit (4) > 




1 1 < 8PSK MEAN BEP TNI : bit (4) >}} 


{0 


1 { <GMSK MEAN BEP TN2 : bit (4) > 




1 1 < 8PSK MEAN BEP TN2 : bit (4) >}} 


{0 


1 { <GMSK MEAN BEP TN3 : bit (4) > 




1 1 < 8PSK MEAN BEP TN3 : bit (4) >}} 


{0 


1 { <GMSK MEAN BEP TN4 : bit (4) > 




1 1 < 8PSK MEAN BEP TN4 : bit (4) >}} 


{0 


1 { <GMSK MEAN BEP TN5 : bit (4) > 




1 1 < 8PSK MEAN BEP TN5 : bit (4) >}} 


{0 


1 { <GMSK MEAN BEP TN6 : bit (4) > 




1 1 < 8PSK MEAN BEP TN6 : bit (4) >}} 


{0 


1 { <GMSK MEAN BEP TN7 : bit (4) > 




1 1 < 8PSK MEAN BEP TN7 : bit (4) >} }; 


< Interference Measurement Report Struct > ::= 


{0| 1 < 


: 1 LEVEL TNO : bit (4) > } 


{0| 1 < 


c 1 LEVEL TNI : bit (4) > } 


{0|1 < 


: 1 LEVEL TN2 : bit (4) > } 


{0| 1 < 


: 1 LEVEL TN3 : bit (4) > } 


{0|1 < 


; 1 LEVEL TN4 : bit (4) > } 


{0| 1 < 


: 1 LEVEL TN5 : bit (4) > } 


{0|1 < 


: 1 LEVEL TN6 : bit (4) > } 


{0| 1 < 


:l LEVEL TN7 : bit (4) > }; 



Table 12.5.4.2: EGPRS Timeslot Link Quality Measurements Information Elements details 



GMSK_MEAN_BEP_TNO (4 bit field) 
GMSK_MEAN_BEP_TN1 (4 bit field) 
GMSK_MEAN_BEP_TN2 (4 bit field) 
GMSK_MEAN_BEP_TN3 (4 bit field) 
GMSK_MEAN_BEP_TN4 (4 bit field) 
GMSK_MEAN_BEP_TN5 (4 bit field) 
GMSK_MEAN_BEP_TN6 (4 bit field) 
GMSK_MEAN_BEP_TN7 (4 bit field) 

These fields contain the mean bit errror probability value calculated on timeslots through 7 for GMSK modulation, 
refer to 3GPP TS 45.008. These fields are transferred only when the mobile station is in packet transfer mode. 
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8PSK_MEAN_BEP_TN0 (4 bit field) 
8PSK_MEAN_BEP_TN1 (4 bit field) 
8PSK_MEAN_BEP_TN2 (4 bit field) 
8PSK_MEAN_BEP_TN3 (4 bit field) 
8PSK_MEAN_BEP_TN4 (4 bit field) 
8PSK_MEAN_BEP_TN5 (4 bit field) 
8PSK_MEAN_BEP_TN6 (4 bit field) 
8PSK_MEAN_BEP_TN7 (4 bit field) 

These fields contain the mean bit errror probability value calculated on timeslots through 7 for 8PSK modulation, 
refer to 3GPP TS 45.008. These fields are transferred only when the mobile station is in packet transfer mode. 

I_LEVEL_TNO (4 bit field) 
I_LEVEL_TN1 (4 bit field) 
I_LEVEL_TN2 (4 bit field) 
I_LEVEL_TN3 (4 bit field) 
I_LEVEL_TN4 (4 bit field) 
I_LEVEL_TN5 (4 bit field) 
I_LEVEL_TN6 (4 bit field) 
I_LEVEL_TN7 (4 bit field) 

These fields contain the y value calculated on timeslots through 7, respectively. The y value is defined in 
3GPP TS 45.008. These fields are encoded relative to C_VALUE as defined for the mapping defined in 
3GPP TS 45.008 for interference level (I_LEVEL); 

bit 

4321 

I_LEVEL 

1 I_LEVEL 1 

1110 I_LEVEL 14 

1111 I_LEVEL 15 



12.6 (void) 

12.7 Channel Request Description 



The Channel Request Description information element is sent by the mobile station to the network to request uplink 
resources. 

Table 12.7.1 : Channel Request Description information elements 

< Channel Request Description IE > ::= 

< PEAK_THROUGHPUT_CLASS : bit (4) > 

< RADIO_PRIORITY : bit (2) > 
<RLC_M0DE:bit(1)> 

< LLC_ PDU_TYPE : bit (1 ) > 

< RLC_OCTET_COUNT : bit (16) > ; 

Table 12.7.2: Ctiannel Request Description information element details 

PEAK_THROUGHPUT_CLASS (4 bit field) 

This field indicates the peak throughput class for the PDP context of the LLC PDU that caused the Channel Request 

Description IE to be transmitted. The field is coded as the binary representation of the Peak Throughput Class specified 

in 3GPP TS 24.008. 

Range: 1 to 9 
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RADIO_PRIORITY (2 bit field) 

This field indicates the Radio Priority of the requested TBF. The field is encoded as the Radio Priority field of the 

Packet Channel Request (see sub-clause 11.2.5). 

RLC_MODE(l bit field) 

This field indicates the RLC mode of the requested TBF. 

RLC acknowledged mode 

1 RLC unacknowledged mode 

LLC_ PDU_TYPE (1 bit field) 

This field indicates the type of the first LLC PDU to be transmitted over the requested uplink TBF. 

LLC PDU is SACK or ACK 

1 LLC PDU is not SACK or ACK 

RLC_OCTET_COUNT (16 bit field) 

The RLC_OCTET_COUNT field indicates the number of RLC data octets, plus the number of RLC data block length 

octets, that the mobile station wishes to transfer. The value '0' indicates that the mobile station does not provide any 

information on the TBF size. 

Range to 65535 



12.7a lu mode Channel Request Description 

The lu mode Channel Request Description information element is sent by the mobile station to the network to request 
uplink resources. 

Table 12.7a.1 : lu mode Channel Request Description information elements 

< lu mode Channel Request Description IE > ;:= 

< RB Id : bit (5) > 

< RADIO_PRIORITY : bit (2) > 

{ I 1 < RLC_BLOCK_COUNT : bit (8) > } 

{ I 1 < lu mode Channel Request Description IE > } ; -IE to be repeated only wtien 
-- In a Multiple TBF request message 

Table 12.7a.2: lu mode Channel Request Description information element details 

RB Id (5 bit field) 

This field indicates the radio bearer identity of the upper layer PDU that caused the lu mode Channel Request 

Description IE to be transmitted. 

Range: to 31 

RADIO_PRIORITY (2 bit field) 

This field indicates the Radio Priority of the requested TBF. The field is encoded as the Radio Priority field of the 

Packet Channel Request (see sub-clause 1 1.2.5). 

RLC_BLOCK_COUNT (8 bit field) 

If present, the RLC_BLOCK_COUNT field indicates the number of RLC data blocks that the mobile station wishes to 
transfer (assuming a CS-1 coding). 

This field is encoded as a binary number as shown: 

bit 
87654321 

00000000 9 RLC data blocks 

00000001 10 RLC data blocks 

11111111 264 RLC data blocks 
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12.7b Extended Channel Request Description 

The Extended Channel Request Description information element is sent by the mobile station to the network to request 
multiple uplink resources. 

Table 12.7b.1 : Extended Channel Request Description information elements 

< Extended Channel Request Description IE > ::= 

< PFI : bit (7) > 

< RADIO_PRIORITY : bit (2) > 
<RLC_M0DE:bit(1)> 

{ I 1 < LLC_ PDU_TYPE : bit (1) > } 

{ I 1 < Extended Channel Request Description IE > } ; - IE to be repeated only when needed and 
-- when included in a Multiple TBF request message 

Table 12.7b.2: Extended Ctiannei Request Description information element details 

PFI (7 bit field) 

This field contains the PFI parameter identifying a Packet Flow Context. The PFI parameter is encoded as the contents 

of the PFI information element as defined in 3GPP TS 44.018. 

RADIO_PRIORITY (2 bit field) 

This field indicates the Radio Priority of the requested TBF. The field is encoded as the Radio Priority field of the 

Packet Channel Request (see sub-clause 1 1.2.5). 

RLC_MODE(l bit field) 

This field indicates the RLC mode of the requested TBF. 

RLC acknowledged mode 

1 RLC unacknowledged mode 

LLC_ PDU_TYPE (1 bit field) 

This field indicates the type of the first LLC PDU to be transmitted over the requested uplink TBF. If the TBF request is 

not for an LLC PDU then this field shall be omitted. 

LLC PDU is SACK or ACK 

1 LLC PDU is not SACK or ACK 



12.8 Frequency Parameters 



The Frequency Parameters information element defines frequency parameters and a training sequence code (TSC), 
which may be allocated to a mobile station to define its channel configuration. All timeslots in the channel 
configuration of the mobile station shall use the same frequency parameters and training sequence code. 

NOTE: For COMPACT, for PDTCH/PACCH on primary and secondary carriers that are indicated in 

EXT_FREQUENCY_LIST by parameter INT_FREQUENCY (see 3GPP TS 45.008), the TSCs should be 
equal to the BCC, as defined in 3GPP TS 23.003, otherwise the accuracy of interference measurement 
reporting may be compromised. 

The frequency parameters may consist of an ARFCN, defining a non-hopping radio frequency channel. The indirect 
encoding, the direct encoding 1 and the direct encoding 2 defines a hopping radio frequency channel. 
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Table 12.8.1 : Frequency Parameters information elements 

< Frequency Parameters IE > ::= 

< TSC : bit (3) > 

{00< ARFCN :bit(10)> 

I 01 < Indirect encoding : < Indirect encoding struct > > 
I 10 < Direct encoding 1 : < Direct encoding 1 struct > > 
I 1 1 < Direct encoding 2 : < Direct encoding 2 struct > > } ; 

< Indirect encoding struct > ::= 

< IVIAIO : bit (6) > 

< l\/IA_NUI\/IBER : bit (4) > 

{ I 1 < CHANGE_MARK_1 : bit (2) > 

{ I 1 < CHANGE_I\/IARK_2 : bit (2) > } } ; 

< Direct encoding 1 struct > ::= 

< IVIAIO : bit (6) > 

< GPRS Mobile Allocation : < GPRS IVIobile Allocation IE > > ; 

< Direct encoding 2 struct > ::= 

< MAIO : bit (6) > 

< HSN : bit (6) > 

< Length of MA Frequency List contents : bit (4) > 

< MA Frequency List contents : octet (val(Length of MA Frequency List contents) + 3) > ; 



Table 12.8.2: Frequency Parameters information element details 

TSC (3 bit field) 

This field is the binary representation of the training sequence code, see 3GPP TS 45.002. Range: to 7. 

ARFCN (10 bit field) 

This field is the binary representation of the absolute radio frequency channel number (ARFCN) defined in 

3GPP TS 45.005. Range to 1023. 

MAIO (6 bit field) 

This field is the binary representation of the mobile allocation index offset (MAIO), see 3GPP TS 45.002. Range to 

63. 

MA_NUMBER (4 bit field) 

This field is the binary reference to a GPRS mobile allocation received in either the PSI2 information, the SI13/PSI13 

information or a previous assignment message, see sub-clause 5.5.1.6. Range: to 15. 

CHANGE_MARK_1 (2 bit field) 

CHANGE_MARK_2 (2 bit field) 

These fields are the binary representations of the allowed values for the PSI or SI change mark associated with the 

GPRS mobile allocation that the MA_NUMBER field refers to. Range: to 3. 

GPRS Mobile Allocation (information element) 

The GPRS Mobile Allocation information element is defined in sub-clause 12.10a. 

HSN (6 bit field) 

This field is the binary representation of the hopping sequence number, see 3GPP TS 45.002. Range: to 63. 

MA Frequency List contents (variable length octet string) 

This variable length octet string is the representation of a set of radio frequency channels defining a GPRS mobile 
allocation. The encoding of the octet string is defined by the value part of the type 4 information element Frequency 
List, defined in 3GPP TS 44.018. The allowed formats of the Frequency List information element are the bit map 0, 
1024 range, 512 range, 256 range, 128 range and variable bit map formats. 
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12.8.1 Abnormal cases 

If the indirect encoding is used, this information element may contain the CHANGE_MARK_1 and 2 fields. If one of 
these fields is present, the receiver shall verify the validity of the PSI or SI change mark associated with the GPRS 
mobile allocation that the MA_NUMBER field refers to, see sub-clause 5.5.1.7. None of the CHANGE_MARK_1 and 
2 fields shall be included if the MA_NUMBER refers to a GPRS mobile allocation received in a previous assignment 
message. 

If the receiver detects that an inconsistency is contained in this information element, the information element shall be 
regarded as invalid. Such inconsistency may be that: 

an invalid PSI or SI change mark is associated with the referred GPRS mobile allocation; 

- an CHANGE_MARK_1 or 2 field is included and the MA_NUMBER refers to a GPRS mobile allocation 
received in a previous assignment message; or 

an undefined MA_NUMBER or an invalid GPRS Mobile Allocation is contained in this information element. 

If the inconsistency is due to an invalid PSI or SI change mark associated with the referred GPRS mobile allocation or 
an undefined MA_NUMBER in the range n 14, the mobile station shall initiate a partial acquisition of PBCCH or 
BCCH information (see sub-clause 5.5.1.4). It shall then obtain the PSI2 or SI13 information, which is concerned. 

12.9 Global Power Control Parameters 

The Global Power Control Parameters information element contains parameters the mobile station shall use to 
determine its TX power level. 

Table 12.9.1 : Global Power Control Parameters information elements 



< Global Power Control Parameters IE > 


;;= 








< ALPHA : bit (4) > 










< T AVG W : bit (5) > 










< T AVG T : bit (5) > 










< Pb : bit (4) > 










< PC_MEAS_CHAN : bit (1) > 










-The value '1' was 


allocated 


in an 


earlier version 


of the protocol and shall not be used. 


< N_AVG_I : bit (4) > ; 











Table 12.9.2: Global Power Control Parameters information element details 



ALPHA (4 bit field) 

This field is the binary representation of the parameter a for MS output power control in units of 0. 1, see 

3GPP TS 45.008. 

Range: to 10. The ALPHA power control parameter field is coded according to the following table: 



bit 




4321 




0000 


a = 0.0 


0001 


a = 0.1 


0010 


a = 0.2 


1001 


a = 0.9 


1010 


a=1.0 



All other values are reserved in this version of the protocol and shall be interpreted by the mobile station as a = 1 .0. 

T_AVG_W (5 bit field) 

The T_AVG_W parameter is a signal strength filter period for power control in packet idle mode. 2*"^^' / 6 multiframes, 

k = 0, 1, 2, ... 25 (see 3GPP TS 45.008). Values greater than 25 shall be interpreted as 25 by the mobile station. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 373 ETSI TS 144 060 V6.28.0 (2010-03) 



T_AVG_T (5 bit field) 

The T_AVG_T parameter is a signal strength filter period for power control in packet transfer mode. 2*"^^' / 6 

multiframes, k = 0,1,2,. ..,25 (see 3GPP TS 45.008). Values greater than 25 shall be interpreted as 25 by the mobile 

station. 

Pb (4 bit field) 

The Pb parameter is a power reduction value used by the BTS on PBCCH blocks, relative to the output power used on 

BCCH. The field is coded according to the following table; 

bit 

4321 

Pb = dB 

1 Pb = -2 dB 

10 Pb = -4 dB 

1111 Pb = -30 dB 

PC_MEAS_CHAN (1 bit field) 

The PC_MEAS_CHAN parameter indicates where the mobile station shall measure the received power level on the 

downlink for the purpose of the uplink power control. 

downlink measurements for power control shall be made on BCCH 

1 downlink measurements for power control shall be made on PDCH 

N_AVG_I (4 bit field) 

The N_AVG_I parameter is an interfering signal strength filter constant for power control 2*"^^', k=0,l,..,15 (see 

3GPPTS 45.008). 

Range: to 15 



12.9a GPRS Power Control Parameters 

The GPRS Power Control Parameters information element contains parameters the mobile station shall use to 
determine its TX power level. 

Table 12.9a.1 : GPRS Power Control Parameters information element 



< GPRS Power Control Parameters IE > ::= 


< ALPHA : bit (4) > 


< T AVG W : bit (5) > 


< T AVG T : bit (5) > 


< PC MEAS CHAN : bit > 


< N AVG 1 : bit (4) > ; 



Table 12.9a.2: GPRS Power Control Parameters information element details 



ALPHA (4 bit field), 

T_AVG_W (5 bit field), 

T_AVG_T (5 bit field), 

PC_MEAS_CHAN (1 bit field) and 

N_AVG_I (4 bit field) 

These fields are defined in the Global Power Control Parameters information element, see sub-clause 12.9. 



12.10 Global TFI 

The Global TFI (Temporary Flow Identity) information element contains either an uplink TFI or a downlink TFI. The 
uplink or downlink TFI identifies a single Temporary Block Flow. 
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Table 12.10.1: Global 7F/ information elements 



< Global TFI IE > ::= 




{ < UPLINK TFI 


: bit (5) > 


1 1 < DOWNLINK 


TFI : bit (5) > } ; 



Table 12.10.2: Global 7F/ information element details 



UPLINK_TFI (5 bit field) 

This field identifies an uplink TBF. This field is coded the same as the TFI field defined in sub-clause 12.15. 

DOWNLINK_TFI (5 bit field) 

This field identifies a downlink TBF. This field is coded the same as the TFI field defined in sub-clause 12.15. 



12.10a GPRS Mobile Allocation 

The GPRS Mobile Allocation information element defines a set of radio frequency channels and a hopping sequence 
number (HSN), which may be allocated to a mobile station to define its channel configuration. 

This information element may refer to a reference frequency list, or set of reference frequency lists defined in the PSI2 
information. In case there is no such reference included in this information element, it refers to the cell allocation (CA) 
defined for the cell. The cell allocation is defined in the PSI2 information, if PBCCH is present in the cell, or in the SIl 
information (see 3GPP TS 44.018), if PBCCH is not present in the cell. 

There are two alternative ways to encode the GPRS mobile allocation, using the MA_BITMAP or the ARFCN index 

hst. 

Table 12.10a.1 : GPRS Mobile Allocation information elements 



< GPRS Mobile Allocation IE > ::= 

< HSN : bit (6) > 

{ I 1 < RFL number list : < RFL number list struct > > } 
{ < MA_LENGTH : bit (6) > 

< MA_BITMAP : bit (val(MA_LENGTH) + 1 ) > 
I 1 { I 1 < ARFCN index list : < ARFCN index list struct > > } } 

< RFL number list struct > ::= 

< RFL_NUIVIBER : bit (4) > 

{ I 1 < RFL number list struct > } ; 

< ARFCN index list struct > ::= 

< ARFCNJNDEX : bit (6) > 

{ I 1 < ARFCN index list struct > } ; 



Table 12.10a.2: GPRS Mobile Allocation information element details 



HSN (6 bit field) 

This field is the binary representation of the hopping sequence number, see 3GPP TS 45.002. Range: to 63. 
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RFL number list (construction) 

This construction is a list specifying the referenced set of reference frequency lists for this information element. If the 

list is not included, this information element refers to the cell allocation defined for the cell. 

The number of radio frequency channels included in the referenced set of reference frequency lists or the referenced cell 
allocation (excluding any duplication of radio frequency channels) is denoted NF. The radio frequency channels shall 
be arranged by the receiver of this information element in the order of ascending ARFCN, except for ARFCN = 0, if 
included, which shall be put last. Each radio frequency channel shall then be assigned an ARFCN_INDEX value, 
ranging from zero, for the first radio frequency channel, to NF-1, for the last radio frequency channel in the ordered set. 

MA_BITMAP (variable length, 1 to 64 bit, field) 

This field is a bitmap representing the radio frequency channels belonging to the GPRS mobile allocation. The number 
of bit positions in MA_BITMAP shall equal NF. The first bit position in MA_BITMAP corresponds to 
ARFCNJNDEX = NF-1, the last position corresponds to ARFCNJNDEX = 0. Each bit position is coded: 

the corresponding radio frequency channel does not belong to the GPRS mobile allocation; 

1 the corresponding radio frequency channel belongs to the GPRS mobile allocation. 

ARFCN index list (construction) 

This construction is a list representing a set of radio frequency channels to be excluded from the definition of the GPRS 

mobile allocation. The GPRS mobile allocation is defined as consisting of the radio frequency channels included in the 

referenced set of reference frequency lists or the referenced cell allocation, except those represented by the ARFCN 

index list. If the list is not included, this information element defines a GPRS mobile allocation consisting of all radio 

frequency channels included in the referenced set of reference frequency lists or the referenced cell allocation, without 

exception. 

RFL_NUMBER (4 bit field) 

This field is the binary reference to a reference frequency list provided in PSI2. Range to 15. 

ARFCNJNDEX (6 bit field) 

This field is the binary reference to a radio frequency channels in the referenced set of reference frequency lists or the 

referenced cell allocation. Range: to NF-1. 



12.10a.1 Abnormal cases 

If the receiver of this information element detects any inconsistency between the encoding of this information element 
and the referenced frequency information (i.e. an MA_BITMAP length or an ARFCNJNDEX value out of range, or an 
undefined RFL_NUMBER value), the information element shall be regarded as invalid. 



12.10b (void) 
12.10c (void) 
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12.10d EGPRS Modulation and coding Scheme description 

This information element defines the modulation and coding scheme to be used. 

Table 12.10d.1 : EGPRS MCS information element details 



EGPRS modulation and coding scheme information element 


bits 
4321 


value 


0000 


MCS-1 


0001 


MCS-2 


0010 


MCS-3 


0011 


MCS-4 


0100 


MCS-5 


0101 


MCS-6 


0110 


MCS-7 


111 


MCS-8 


1000 


MCS-9 


1 001 


MCS-5-7 


1010 


MCS-6-9 


1011 
to 

1111 


reserved 



12.10e RESEGIVIENT description 



The RESEGMENT field defines whether retransmitted uplink RLC data blocks shall be re-segmented or not. 

Table 12.10e.1: /7ESEGMEA/7 information element details 

RESEGMENT (1 bit field) 

Retransmitted RLC data blocks shall not be re-segmented 

1 Retransmitted RLC data blocks shall be re-segmented according to commanded MCS 



12. 11 Packet Request Reference 



The purpose of the Packet Request Reference information element is to provide the information field sent in the Packet 
Channel Request (i.e. the PACKET CHANNEL REQUEST or EGPRS PACKET CHANNEL REQUEST message) and 
the frame number, FN modulo 42432, in which the Packet Channel Request was received. 

Table 12.1 1 .1 : Packet Request Reference information elements 

< Packet Request Reference IE > ::= 

< RANDOM_ACCESSJNFORI\/IATION value : bit (1 1) > 

< FRAME_NUMBER : bit (16) > ; 
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Table 12.1 1 .2: Packet Request Reference information element details 

RANDOM_ACCESS_INFORMATION value (1 1 bit field) 

This is an unformatted 1 1 bit field. If the mobile station used the 1 1-bit message format in the Packet Channel Request, 

all 1 1 bits of this field are valid. Otherwise, only bits 8 through 1 are valid and bits 1 1 through 9 shall be set to '0' 





Bit 




11 


10 


9 


8 


7 


6 


5 


4 


3 


2 


1 


11 -bit message format used 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


X 


8-bit message format used 











X 


X 


X 


X 


X 


X 


X 


X 



FRAME_NUMBER (16 bit field) 

This field is encoded the same as the Starting Time information element defined in 3GPP TS 44.018. 



12.12 Packet Timing Advance 



The Packet Timing Advance field describes the timing advance mode and timing advance value assigned to the mobile 
station. 

Table 12.12.1 : Packet Timing Advance information elements 

< Pacl<et Timing Advance IE > ::= 

{ I 1 < TIMING_ADVANCE_VALUE : bit (6) > } 
{ I 1 < TIMING_ADVANCEJNDEX : bit (4) > 
< TIMING_ADVANCE_TIMESLOT_NUMBER : bit (3) > } ; 

Table 12.12.2: Packet Timing Advance information element details 

TIMING_ADVANCE_VALUE (6 bit field) 

If the TIMING_ADVANCE_VALUE field is present, the mobile station shall use the value contained therein after time 
defined in 3GPP TS 45.010. If the TIMING_ADVANCE_ VALUE field is not present the mobile station shall not 
change its timing advance value. The Timing Advance value field is encoded the same as the Timing Advance value of 
the Timing Advance information element defined in 3GPP TS 44.018 

TIMING_ADVANCE_INDEX (4 bit field) 

If the TIMING_ADVANCE_INDEX and TIMING_ADVANCE_TIMESLOT_NUMBER fields are present the mobile 

station shall begin operation of the Continuous Timing Advance procedure at the point in time denoted by the TBF 

starting time if present, otherwise after the reaction time specified in 3GPP TS 45.010.. If these two fields are not 

present the mobile station shall stop operation of the Continuous Timing Advance procedure. This information field is 

encoded as a binary representation of the Timing Advance Index defined in 3GPP TS 45.002. 

Range to 15. 

TIMING_ADVANCE_TIMESLOT_NUMBER (3 bit field) 

This field indicates the timeslot assigned for the Continuous Timing Advance procedure on the PTCCH. This field is 

coded as the binary representation of the timeslot number as defined in 3GPP TS 45.010. 

Range to 7 
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12.12a Global Packet Timing Advance 



The Global Packet Timing Advance field describes the timing advance mode and timing advance value assigned to the 
mobile station for uplink and/or downlink TBF. 

Table 12.12a.1 : Global Packet Timing Advance information elements 

< Global Packet Timing Advance IE > ::= 

{ I 1 < TIMING_ADVANCE_VALUE : bit (6) > } 

{ I 1 < UPLINK_TIMING_ADVANCE_INDEX : bit (4) > 

< UPLINK_TIMING_ADVANCE_TIMESLOT_NUMBER : bit (3) > } 
{ I 1 < DOWNLINK_TIMING_ADVANCEJNDEX : bit (4) > 
< DOWNLINK_TIMING_ADVANCE_TIMESLOT_NUMBER : bit (3) > } 

Table 12.12a.2: Global Packet Timing Advance information element details 

TIMING_ADVANCE_VALUE (6 bit field) 

If the TIMING_ADVANCE_VALUE field is present, the mobile station shall use the value contained therein after time 
defined in 3GPP TS 45.010. If the TIMING_ADVANCE_ VALUE field is not present the mobile station shall not 
change its timing advance value. The Timing Advance value field is encoded the same as the Timing Advance value of 
the Timing Advance information element defined in 3GPP TS 44.018 

UPLINK_TIMING_ADVANCE_INDEX (4 bit field) 

This field indicates the Timing Advance Index related to Uplink TBF. This information field is encoded as a binary 

representation of the Timing Advance Index defined in 3GPP TS 45.002. 

Range to 15. 

UPLINK_TIMING_ADVANCE_TIMESLOT_NUMBER (3 bit field) 

This field indicates the timeslot assigned for the Continuous Timing Advance procedure on the PTCCH related to 
Uplink TBF. This field is coded as the binary representation of the timeslot number as defined in 3GPP TS 45.010. 
Range to 7 

DOWNLINK_TIMING_ADVANCE_INDEX (4 bit field) 

This field indicates the Timing Advance Index related to Downlink TBF. This information field is encoded as a binary 

representation of the Timing Advance Index defined in 3GPP TS 45.002. 

Range to 15. 

DOWNLINK_TIMING_ADVANCE_TIMESLOT_NUMBER (3 bit field) 

This field indicates the timeslot assigned for the Continuous Timing Advance procedure on the PTCCH related to 
Downlink TBF. This field is coded as the binary representation of the timeslot number as defined in 3GPP TS 45.010. 
Range to 7 

If Timing Advance Index and Timing Advance Timeslot Number are present for any of the TBFs already existing or to 
be established with this message, the mobile station shall begin operation of the Continuous Timing Advance procedure 
at the point in time denoted by the TBF starting time if present, otherwise within the reaction time specified in 
3GPPTS 45.010. 

If Timing Advance Index and Timing Advance Timeslot Number are not present for any of the TBFs already existing 
or to be established with this message, the mobile station shall stop operation of the Continuous Timing Advance 
procedure. 
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12.12b Packet Extended Timing Advance 

The Packet Extended Timing Advance field is a 2 bit field used to support Extended Timing Advance. These two bits 
represent the two most significant bits of the timing advance value to be applied by the mobile station. The coding of 
the timing advance value is defined in the Timing Advance IE defined in 3GPP TS 44.018. The mapping of the two bits 
of the Packet Extended Timing Advance field is defined as follows; 

Bit 

1 bit 7 of the Timing Advance IE defined in 3GPP TS 44.0 1 8 

2 bit 8 of the Timing Advance IE defined in 3GPP TS 44.0 1 8 

The least significant bits of a timing advance value is provided the TIMING_ADVANCE_VALUE field in either a 
Packet Timing Advance IE (sub-clause 12.12) or a Global Packet Timing Advance IE (sub-clause 12.12a). If the least 
significant bits of the timing advance value is not provided in the message, then the Packet Extended Timing Advance 
field shall be ignored. 

12.13 Power Control Parameters 

The Power Control parameters information element contains parameters the mobile station shall use to determine its TX 
power level. 

Table 12.13.1 : Power Control Parameters information elements 



< Power Control Parameters IE > ::= 


< ALPHA : bit (4) 


> 




{0 


1 < GAMMA 


TNO 


bit (5) > } 


{0 


1 < GAMMA 


TNI 


bit (5) > } 


{0 


1 < GAMMA 


TN2 


bit (5) > } 


{0 


1 < GAMMA 


TN3 


bit (5) > } 


{0 


1 < GAMMA 


TN4 


bit (5) > } 


{0 


1 < GAMMA 


TN5 


bit (5) > } 


{0 


1 < GAMMA 


TN6 


bit (5) > } 


{0 


1 < GAMMA 


TN7 


bit (5) > } ; 
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Table 12.13.2: Power Control Parameters information element details 



ALPHA (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 

GAMMA_TNO (5 bit field) 

GAMMA_TN1 (5 bit field) 

GAMMA_TN2 (5 bit field) 

GAMMA_TN3 (5 bit field) 

GAMMA_TN4 (5 bit field) 

GAMMA_TN5 (5 bit field) 

GAMMA_TN6 (5 bit field) 

GAMMA_TN7 (5 bit field) 

The GAMMA_TN0..7 fields are the binary representation of the parameter Tch for MS output power control in units of 

2 dB, see 3GPP TS 45.008. GAMMA_TNO contains the gamma value for timeslot number 0, GAMMA_TN1 contains 

the gamma value for timeslot number 1, etc. If this information element is also used to determine the timeslot allocation 

for an uplink TBF, for each timeslot, the presence of the GAMMA value indicates that the timeslot is assigned, and the 

absence of the GAMMA value indicates that the timeslot is not assigned (see sub-clause 12.18). The GAMMA_TN0..7 

field is coded according to the following table: 

bit 

5432 1 

Tch = dB 

1 Tch = 2 dB 

11110 Tch = 60 dB 

11111 Tch = 62 dB 



12.14 PRACH Control Parameters 

The purpose of the PRACH Control Parameters information element is to provide parameters used to control the 
PRACH utiUzation. 

Table 12.14.1: PRACH Control Parameters information elements 



< PRACH Control Parameters IE > ::= 




<ACC CONTR CLASS: bit (16) 


> 


< MAX RETRANS : bit (2) > * 4 




< S : bit (4) > 




< TX INT : bit (4) > 




{ 1 1 < PERSISTENCE LEVEL : 


bit (4) > * 4 } ; 
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Table 12.14.2: PRACH Control Parameters information element details 

TXJNT (4 bit field) 

Number of slots to spread transmission of the random access. The field is coded according to the following table: 

bit 

4321 

0000 

0001 

0010 

001 1 

0100 

0101 

0110 

111 
1000 
1001 
1010 
1011 

1 100 
1101 
1110 

1111 



2slots used to spread transmission 

3 slots used to spread transmission 

4 slots used to spread transmission 

5 slots used to spread transmission 

6 slots used to spread transmission 

7 slots used to spread transmission 

8 slots used to spread transmission 

9 slots used to spread transmission 

10 slots used to spread transmission 
12 slots used to spread transmission 
14 slots used to spread transmission 
16 slots used to spread transmission 
20 slots used to spread transmission 
25 slots used to spread transmission 
32 slots used to spread transmission 
50 slots used to spread transmission 



S (4 bit field) 

S is a parameter used for calculation of the minimum number of slots between two successive Channel request 

messages. The field is coded according to the following table: 



bit 




4321 




0000 


S = 12 


0001 


S = 15 


0010 


S = 20 


001 1 


S = 30 


0100 


S=41 


0101 


S = 55 


Olio 


S = 76 


111 


S = 109 


1000 


S = 163 


1001 


S = 217 



All other values reserved. 
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MAX_RETRANS (2 bit field for each Radio Priority 1..4) 

Indicates for each Radio Priority level 1 to 4 the maximum number of retransmissions allowed. Radio Priority 1 
represents the highest priority. The field is coded with two bits per Radio Priority level according to the following table 
where the first two bits refer to Radio Priority 1, the second two bits to Radio Priority 2, etc.: 

bit 

2 1 

1 retransmission allowed 

1 2 retransmissions allowed 

10 4 retransmissions allowed 

11 7 retransmissions allowed 

PERSISTENCE_LEVEL (4 bit field for each Radio Priority 1..4) 

The PERISTENCE_LEVEL field indicates the values of the access persistence level P(i) for each Radio Priority i (i = 

1..4) where Radio Priority 1 represents the highest Radio Priority of an LLC PDU to be transmitted. 

bits 

4321 

persistence level 

1 persistence level 1 

10 persistence level 2 

11 persistence level 3 

1 .0.0 persistence level 4 

1110 persistence level 14 

1111 persistence level 16 

ACC_CONTR_CLASS ( 16 bit field) 

Access Control Class N (bit 1-16) (see octet 3 and 4 of the RACH Control Parameters IE in 3GPP TS 44.018) . For a 
mobile station with Access Control Class =N access is not barred if the Access Control Class N bit is coded with a '0'; 
N = 0, 1,....9,1 1,...,15. Bit 1 1= the EC bit is the Emergency Call Allowed coded as specified in 3GPP TS 44.018. 






Bits: 


16 


15 


14 


13 


12 


11 


10 


9 


8 


7 


6 


5 


4 


3 


2 


1 




Class N: 


15 


14 


13 


12 


11 


EC 


9 


8 


7 


6 


5 


4 


3 


2 


1 






12.15 Temporary Flow Identity (TFI) 



The Temporary Flow Identity (TFI) uniquely identifies either a single uplink Temporary Block Flow (TBF) or a single 
downlink Temporary Block Flow (TBF). 



Table 12.15.1 : UPLINK TFI information element details 



UPLINK_TFI (5 bit field) 

The Temporary Flow Identity field identifies an uplink Temporary Block Flow (TBF). This field is encoded as a binary 

number. 

Range to 31 



Table 12.15.2: DOWNLINK 7F/ information element details 



DOWNLINK_TFI (5 bit field) 

The Temporary Flow Identity field identifies a downlink Temporary Block Flow (TBF). This field is encoded as a 

binary number. 

Range to 31 
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12.16 Temporary Logical Link Identity (TLLI)/G-RNTI 

The Temporary Logical Link Identity (TLLI) is associated with the GPRS subscriber. TLLI is defined in 
3GPP TS 23.003. 

The TLLI codespace is re-used in some messages and contains the first 28 bits of the G-RNTI as defined in 
3GPP TS 23.003. The G-RNTI is defined in 3GPP TS 44. 160. 

Table 12.16.1 : TLLI information element details 

TLLI /G-RNTI (32 bit field) 

The TLLI / G-RNTI field is encoded as a binary number. 

Range to 4294967295 



12.16a GERAN Radio Network Temporary Identity (G-RNTI) 

The G-RNTI (GERAN Radio Network Temporary Identity) is allocated to an MS at the RRC layer having a RRC 
connection and identifies the MS within GERAN. It is used by the RLC/MAC layer for contention resolution and to 
identify an MS. 

NOTE: The RRC layer uses the G-RNTI defined in 44. 11 8 

< G-RNTI IE>::= 

< S-RNTI : bit (20) > 

< Serving BSC Identity : bit (12) > ; 

Serving BSC identity (12 bit field) 

This field identifies the mobile station's serving BSC in GERAN. 

S-RNTI (20 bit field) 

This field identifies the mobile station within the serving BSC. 



12.17 Temporary Queueing Identifier (TQI) 

The Temporary Queueing Identifier (TQI) field identifies a mobile station during the queueing procedure. The contents 
of this field are operator defined. 

Table 12.17.1: 70/ information element details 

TQI (16 bit field) 

The Temporary Queueing Identifier field is an unformatted field. 
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12.18 TIMESLOT_ALLOCATION 

The TIMESLOT_ALLOCATION field indicates the timeslots for use during a TBF or the timeslots carrying a PCCCH. 
Table 12.18.1 : TIMESLOT_ALLOCATION information element details 

TIMESLOT_ALLOCATION (8 bit field) 

This information field indicates the timeslots assigned for use during the TBF or the timeslots carrying a PCCCH. Bit 8 

indicates the status of timeslot 0, bit 7 indicates the status of timeslot 1, etc. At least one timeslot must be assigned. 

Timeslot is not assigned 

1 Timeslot is assigned 



12.19 (void) 

12.20 PAGE_MODE 

The PAGE_MODE field controls the action of the mobile station belonging to the paging subgroup corresponding to 
the paging subchannel. 

Table 12.20.1 : PAGE_MODE information eiement detaiis 

PAGE_MODE (2 bit field) 

bit 

2 1 value 

Normal Paging 

1 Extended Paging 

1 Paging Reorganization 
1 1 Same as before 



12.21 Starting Frame Number Description 

There are two types of encoding for this IE : Relative Frame Number or Absolute Frame Number. 

Table 12.21 .1 : Starting Frame Number Description information element 

< Starting Frame Number Description IE > ::= 
{ < Absolute Frame Number Encoding > 
I 1 < Relative Frame Number Encoding > } ; 

If the mobile station is in packet transfer mode during the block immediately before the starting time and the lowest 
numbered PDCH assigned to the MS is different immediately before and after the starting time then the mobile station 
shall be ready to receive or transmit no later than one radio block from the starting time (see 3GPP TS 45.002). 



1 2.21 .1 Absolute Frame Number Encoding 



In this case, the field is encoded as the 16-bit Starting Time IE defined in 3GPP TS 44.018, and the value of the Starting 
FN is obtained directly. 

If the Starting FN is not aligned to the start of a block period and the mobile station is in packet transfer mode during 
the TDMA immediately before the Starting FN, then the mobile station shall align the starting time to the next block 
boundary and continue to use the currently assigned allocation upto the next block boundary. 
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1 2.21 .2 Relative Frame Number Encoding 



In this case, the field indicates the delay, relative to the first TDMA frame (N) of the RLC/MAC block containing the 
Starting Time field, before the assigned or requested resource becomes valid. 

The value of this field is the 1 3 bit binary representation of the integer k, from which the offset to be applied to N can 
be derived. 

The value of the Starting Frame Number is calculated as follows: 



For (k mod 3) equal to: 


The value of the Starting Frame Number Is: 


Oor1 


N+4 + 4k + {k div3), N + 5 + 4k + (k div3)(N0TE 1 ) 


2 


N + 5 + 4k + (k div3) 


0<k<8191 



EXAMPLE: Starting Frame Number Description (13-bit field): 

k = 1 000000000000 1 block with first TDMA frame number = N+8 or N+9 

k = 2 00000000000 1 block with first TDMA frame number = N+ 1 3 

k = 3 00000000000 1 1 block with first TDMA frame number = N+ 1 7 or N+ 1 8 

NOTE 1: In these cases, only one of the frame numbers N+4+4k+kdiv3 or N+5+4k+kdiv3 is valid, because the 
other corresponds to an idle frame, depending on the position of the block in the multi-frame. 

NOTE 2: The value of (k-nl) gives the number of relative blocks. The maximum number of relative blocks is 

therefore 8 192; this value was chosen according to the interval of time encoded by the Starting Time IE 
in 3GPP TS 44.018 (32 024 frames). 

NOTE 3: The value (k=0) should not be used, so as to leave time for the MS to analyse the message and get ready 
to receive or transmit. 



12.22 (void) 



12.23 Cell Identification 

The Cell Identification information element is used to uniquely identify the cell. 

Table 12.23.1: Cell Identification information element 



< Cell Identification IE > ::= 

< Location Area Identification IE : octet (5) > - 3GPP TS 44.018 

< RAC : bit (8) > 

< Cell Identity IE : octet (2) > ; - 3GPPTS 44.018 



Table 12.23.2: Cell Identification information element details 



Location Area Identity IE (5 octet field) 

This field is coded using the V format of the type 3 information element Location Area Identification defined in 

3GPPTS 44.018. 



RAC (8 bit field) 

This field is the binary representation of the Routing Area Code, see 3GPP TS 23.003. 



Cell Identity IE (2 octet field) 

This field is coded using the V format of the type 3 information element Cell Identity defined in 3GPP TS 44.018. 
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12.24 GPRS Cell Options 

The GPRS Cell Options information element is used to control a set of cell options related to GPRS. 

This information element may include a nested Extension Bit information element to allow future extension of cell 
option parameters. 

Table 12.24.1 : GPRS Cell Options information element 

< GPRS Cell Options IE > ::= 

< NMO : bit (2) > 
<T3168:bit(3)> 
<T3192:bit(3)> 

< DRX_TIMER_MAX : bit (3) > 

< ACCESS_BURST_TYPE : bit > 

< CONTROL_ACK_TYPE : bit > 

< BS_CV_MAX : bit (4) > 

{ I 1 < PAN_DEC : bit (3) > 

< PANJNC : bit (3) > 

< PAN_MAX : bit (3) > } 

~ Optional extension information: 
{ I 1 < Extension Length : bit (6) > 

< bit (val(Extension Length) + 1) 

& { <Extension Information > ! { bit ** = <no strjng> } } > } ; 

< Extension lnformation> : : = 

{ { -- R99 extension: 

{ I 1 - EGPRS supported by tlie cell if the choice bit is set to '1 ' 

< EGPRS_PACKET_CHANNEL_REQUEST : bit > 

< BEP_PERIOD : bit (4) > } 

< PFC_FEATURE_MODE: bit > 

< DTM_SUPPORT: bit > 

< BSS_PAGING_COORDINATION: bit > } 
{ -- REL-4 extension: 

< CCN_ACTIVE : bit > 

< NW_EXT_UTBF : bit > } 
{ -- REL 6 extension: 

< MULTIPLE_TBF_CAPABILITY : bit > 

< EXT_UTBF_NO_DATA : bit > 

< DTM_ENHANCEMENTS_CAPABILITY : bit > 

{ -- MBMS procedures not supported by the cell if the choice bit is set to '0' 

I 1 -- MBMS procedures supported by the cell if the choice bit is set to '1 ' 

< DEDICATED_MODE_MBMS_NOTIFICATION_SUPPORT: bit > 

< MNCLSUPPORT : bit > } } 

< spare bit >**}//; -- Extension information may be truncated between released versions of the protocol. 

- The receiver shall assume the value zero for any truncated bit. 
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Table 12.24.2: GPRS Cell Options information element details 

NMO (2 bit field) 

This field is the binary representation of the Network Mode of Operation, see 3GPP TS 23.060: 

Bit 
2 1 

Network Mode of Operation I 

1 Network Mode of Operation II 

1 Network Mode of Operation III 
1 1 Reserved. 

T3168 (3 bit field) 

This field is the binary representation of the timeout value of timer T3 168. Range: to 7. The timeout value is given as 

the binary value plus one in units of 500 ms. 

T3192 (3 bit field) 

This field is the binary representation of the timeout value of timer T3 192. Range: to 7. The timeout value is given in 
the following table. In the case of ms, the timer is not started and the mobile station shall consider T3192 as 
immediately expiring and follow procedures defined in sub-clauses 9.3.2.6 and 9.3.3.5: 



Bit 




321 




000 


500 ms 


001 


1000 ms 


010 


1500 ms 


1 1 


ms 


1 00 


80 ms 


1 01 


120 ms 


1 10 


160 ms 


1 1 1 


200 ms 



DRX_TIMER_MAX (3 bit field) 

This field is the binary representation of the parameter DRX_TIMER_MAX. Range: to 7. The parameter value is 
given as two taken to the power of the binary value minus one (2 *''^ " '' ) in units of 1 second. The binary value zero 
indicates the parameter value zero (i.e, the parameter takes the values: 0, 1 s, 2 s, 4 s, .. 64 s.) 

ACCESS_BURST_TYPE (1 bit field) 

The ACCESS_BURST_TYPE field indicates if the 8 or 1 1 bit format shall be used in the PACKET CHANNEL 
REQUEST message, the PS HANDOVER ACCESS message, the PTCCH uplink block (3GPP TS 44.004) and in the 
PACKET CONTROL ACKNOWLEDGMENT message when the format is four access bursts. The field is coded 
according to the following table: 

8 -bit format shall be used 

1 11 -bit format shall be used 

CONTROL_ACK_TYPE (1 bit field) 

This field is the binary representation of the default format of the PACKET CONTROL ACKNOWLEDGMENT 

message: 

default format is four access bursts 

1 default format is RLC/MAC control block. 

BS_CV_MAX (4 bit field) 

This field is the binary representation of the parameter BS_CV_MAX. Range: to 15. The value BS_CV_MAX=0 

shall be interpreted as value BS_CV_MAX=1 for calculation of T3200 and N3104max values. 

PAN_DEC (3 bit field) 

This field is the binary representation of the parameter PAN_DEC. If the field in not included, the default value shall 

be used. Range: to 7. 

PANJNC (3 bit field) 

This field is the binary representation of the parameter PANJNC. If the field in not included, the default value shall 

be used. Range: to 7. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 388 ETSI TS 144 060 V6.28.0 (2010-03) 

PAN_MAX (3 bit field) 

This field defines the maximum value allowed for counter N3102. 

bit 

321 

maximum value allowed for counter N3 102 is 4 

1 maximum value allowed for counter N3102 is 8 

111 maximum value allowed for counter N3102 is 32 

If the PAN_MAX field in not included, the default value (i.e. N3102 max = 4) shall be used. 

EGPRS_PACKET_CHANNEL_REQUEST (1 bit field) 

EGPRS capable MSs shall use EGPRS PACKET CHANNEL REQUEST message for uplink TBF estabUshment on 
the PRACH when there is a PBCCH in the cell or on the RACH when there is no PBCCH in the cell. 

1 EGPRS capable MSs shall use two phase packet access with PACKET CHANNEL REQUEST message on the 
PRACH for uplink TBF establishment when there is a PBCCH in the cell. EGPRS capable MSs shall use two phase 
packet access with CHANNEL REQUEST message on the RACH when there is no PBCCH in the cell. 

BEP_PERIOD (4 bit field) 

This field contains the bit error probability (BEP) filter averaging period, refer to 3GPP TS 45.008. 

PFC_FEATURE_MODE (1 bit field) 

The network does not support packet flow context procedures. 

1 The network supports packet flow context procedures. 

DTM_SUPPORT (1 bit field) 

This field indicates whether the cell supports DTM or not. It is coded as follows: 

The cell does not support DTM procedures. 

1 The cell supports DTM procedures. 

CCN_ACTIVE (1 bit field) 

This field indicates whether CCN is enabled in the cell or not. It is coded as follows: 

CCN is disabled in the cell. 

1 CCN is enabled in the cell. 

NW_EXT_UTBF (1 bit field) 

This field indicates whether the network supports the extended uplink TBF mode: 

The extended uplink TBF mode is not supported by the network. 

1 The extended uplink TBF mode is supported by the network. 

BSS_PAGING_COORDINATION (1 bit field) 

This field indicates the network support of CS paging co-ordination in packet transfer mode during network mode of 
operation II and III. This field shall be ignored by the mobile station during network mode of operation I or by a mobile 
station capable of DTM in a cell supporting DTM procedures, in which cases Circuit-Switched paging coordination in 
packet transfer mode shall be provided by the network. It is coded as follows: 

The cell does not support Circuit-Switched paging coordination 

1 The cell supports Circuit-Switched paging coordination 

MULTIPLE_TBF_CAPABILITY (1 bit field) 

This field indicates whether or not the cell supports multiple TBF procedures for A/Gb mode: 

The cell does not support multiple TBF procedures. 

1 The cell supports multiple TBF procedures. 
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EXT_UTBF_NODATA (1 bit field) 

This field indicates whether the mobile station during extended uplink TBF mode may refi^ain fi^om sending PACKET 
UPLINK DUMMY CONTROL BLOCK messages when there is no other RLC/MAC block ready to send in an uplink 
radio block allocated by the network. 

The mobile station shall send a PACKET UPLINK DUMMY CONTROL BLOCK message when there is no 
other RLC/MAC block ready to send in an uplink radio block allocated by the network. 

1 The mobile station may refrain from sending a PACKET UPLINK DUMMY CONTROL BLOCK message 
when there is no other RLC/MAC block ready to send in an uplink radio block allocated by the network. 

DTM_ENHANCEMENTS_CAPABILITY (1 bit field) 

This field indicates whether the cell supports enhanced DTM CS establishment and enhanced DTM CS release or not. It 

is coded as follows: 

The cell does not support enhanced DTM CS establishment and enhanced DTM CS release procedures. 

1 The cell supports enhanced DTM CS establishment and enhanced DTM CS release procedures. 

DEDICATED_MODE_MBMS_NOTIFICATION_SUPPORT (1 bit field) 

This field indicates whether the cell supports Dedicated Mode MBMS Notification or not. It is coded as follows; 

The cell does not support the Dedicated Mode MBMS Notification procedures. 

1 The cell supports the Dedicated Mode MBMS Notification procedures. 

MNCI_SUPPORT (1 bit field) 

This field indicates whether the cell supports the distribution of MBMS NEIGHBOURING CELL INFORMATION 

messages. It is coded as follows: 

The cell does not support the distribution of MBMS NEIGHBOURING CELL INFORMATION messages 

1 The cell supports the distribution of MBMS NEIGHBOURING CELL INFORMATION messages 



12.25 PCCCH Organization Parameters 

The PCCCH Organization Parameters information element is used to control the organization of PCCCHs present in 
the cell. This information element contains general PCCCH organization parameters. 

Table 12.25.1 : PCCCH Organization Parameters information element 

< PCCCH Organization Parameters IE > ::= 

< BS_PCC_REL : bit > 

< BS_PBCCH_BLKS : bit (2) > 

< BS_PAG_BLKS_RES : bit (4) > 

< BS_PRACH_BLKS : bit (4) > ; 

Table 12.25.2: PCCCH Organization Parameters information element details 

BS_PCC_REL (1 bit field) 

The BS_PCC_REL field indicates if set = 1 that the last PDCH carrying PCCCH and PBCCH will be released shordy. 
All mobile stations on PCCCH shall then as soon as this information has been received return to CCCH and there obey 
the information sent on BCCH as specified in 3GPP TS 44.018. If the field is set = 0, no channel release is pending. 

BS_PBCCH_BLKS (2 bit field) 

The BS_PBCCH_BLKS field indicates the number of blocks allocated to the PBCCH in the multiframe. The field is 

coded as the binary representation of BS_PBCCH_BLKS as defined in 3GPP TS 45.002 minus 1. 
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BS_PAG_BLKS_RES (4 bit field) 

The BS_PAG_BLKS_RES field indicates the number of blocks on each PDCH carrying the PCCCH per multiframe 
where neither PPCH nor PBCCH should appear. The field is coded as the binary representation of 
BS_PAG_BLKS_RES as defined in 3GPP TS 45.002. Range: 0-10. The BS_PAG_ BLKS_RES value shall fulfil the 
condition that is defined in 3GPP TS 45.002. If the condition is not fulfilled, then the behaviour of the mobile station is 
implementation dependent. 

BS_PRACH_BLKS (4 bit field) 

The BS_PRACH_BLKS field indicates the number of blocks reserved in a fixed way to the PRACH channel on any 
PDCH carrying PCCCH (see 3GPP TS 45.002). The field is coded as the binary representation of BS_PRACH_BLKS 
as defined in 3GPP TS 45.002. Range: 0-12. All other values are reserved and shall be interpreted as no Block reserved 
for PRACH. 



12.26 Extension Bits IE 

The Extension Bits information element is used to provide a generalized means for possible future extension within a 
message. This information element is variable length and contains the length indicator and spare bits. 

Table 12.26.1 : Extension Bits information element 



< Extension Bits IE > ::= 

< extension length : bit (6) > 

< spare bit (val(extension lengtli)+1) > 



1 2.27 Non GPRS Cell Options IE 



The Non GPRS Cell Options IE is used to provide mobile stations operating in mode A or B with a repeated subset of 
BCCH information required for entering dedicated, group receive or group transmit mode. 

Table 12.27.1 : Non GPRS Cell Options information element 



< Non GPRS Cell Options IE > ::= 




< ATT : bit > 


- Attacii/Detacti allowed 


{0|1 <T3212:bit(8)>} 


- Time-out value for periodic update 


< NECI : bit > 


- Half rate support 


< PWRC : bit > 


- Power Control indicator 


< DTX : bit (2) > 


- DTX indicator 


< RADIO-LINK-TIMEOUT : bit (4) > 


-- Supervisory timer for RR connection 


< BS-AG-BLKS-RES : bit (3) > 


- number of blocks reserved for access grant 


< CCCH-CONF : bit (3) > 


- ptiysicai channel configuration for CCCH 


< BS-PA-MFRIMS : bit (3) > 


- number of 51 multi frames between 




- transmission of paging messages 


< IVIAX-RETRANS : bit (2) > 


- maximum number of retransmissions 


< TX-INTEGER : bit (4) > 


- number of slots to spread transmission 


< EC : bit > 


- emergency call allowed 


< IVIS-TXPWR-MAX-CCCH : bit (5) > 


- maximum Tx power level 


- Optional extension information: 




{ 1 1 < Extension Length : bit (6) > 




< bit (val(Extension Length) + 1) 




& { <Extension Information > ! { bit 


** = <no string> } } > } ; 


< Extension Information > ::= 




< ECSC: bit > 


- Early Classmark Sending Control 


< 3G ECSR > 


- 3G Early Classmark Sending Restriction 


< spare bit > ** ; 
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Table 12.27.2: Non GPRS Cell Options information element details 

For detailed descriptions of all elements see 3GPP TS 44.018. 

If the optional T3212 parameter is not included, no periodic updating shall be performed. 

ECSC(1 bit field) 

This field defines the Early Classmark Sending Control. 

Early Classmark Sending is forbidden 

1 Early Classmark Sending is allowed 

If the optional ECSC parameter is not included, early classmark sending is allowed. For a detailed description see 
3GPPTS 44.018. 

3GECSR(1 bit field) 

This field defines the 3G Early Classmark Sending Restriction. 

Neither UTRAN nor cdma2000 classmark change message shall be sent with the Early Classmark Sending 

1 The sending of UTRAN and CDMA2000 Classmark Sending messages is controlled by the Early Classmark 
Sending Control parameter 

If the optional 3G Early Classmark Sending Restriction parameter is not included, the default value '0' shall be assumed. 
For a detailed description see 3GPP TS 44.018. 



12.28 LSA Parameters 

The LSA Parameters information element is used for cell reselection by SoLSA mobile stations. The IE contains a list 
of LS A_ID(s) corresponding either to the entries in the 'Add Frequency list struct' defined in the Packet Cell Change 
Order message and in Packet Measurement Order message or to the entries in the Neighbour Cell Parameters when used 
in the packet System Information 3 and 3bis messages. Some entries in the 'LSA parameters IE' may be empty. In case 
there are too few entries in the 'LSA parameters IE', empty entries shall be added at the end. In case there are too many 
entries in the 'LSA parameters IE', the last shall be discarded. 

Table 12.28.1 : LSA Parameters information element 

< LSA Parameters IE > ::= 

< NR_OF_FREQ_OR_CELLS : bit (5) >: 

{ < LSA ID information : < LSA ID information struct » * (val(NR_OF_FREQ_OR_CELLS)) }; 

< LSA ID information struct > ::= 

{ 1 { < LSAJD : bit (24) > 

|1 < ShortLSAJD : bit (10) >} } '* ; 

Table 12.28.2: LSA Parameters information element details 

LSAJD (24 bit field) 

The purpose of the LSAJD field is to identify a LSA. The LSA ID value field is coded as specified in 

3GPPTS 23.003. 

Short LSAJD (10 bit field) 

The purpose of the Short LSAJD field is to identify a LSA. The LSA ID defined by the Short LSAJD is a LSAJD as 
specified in 3GPP TS 23.003 with bit set to "0" bit 1 to 10 set to the value of the Short LSAJD field (LSB in bit 1, 
MSB in bit 10) and bit 1 1 to 23 set to "0". 
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1 2.29 COMPACT reduced MA 

Table 12.29.1: COMPACT reduced MA information element 

< COMPACT reduced MA IE > ::= 

<Length of Reduced MA bitmap : bit (7) > 

<Reduced MA bitmap : bit( val( Length of Reduced MA bitmap ) ) > 

{ I 1 <MAI0_2 : bit(6) >}; 

Table 12.29.2: COMPACT reduced MA information element details 

Length of Reduced MA bitmap (7 bit field) 

This field is the binary representation of the length (in bits) of the field Reduced MA bitmap. 

If set to 0, then no reduced Mobile Allocation is used. 

Range to 127. 

Reduced MA bitmap (bitmap) 

This field gives the reduced Mobile Allocation. 

This bitmap uses the list of frequencies given in the current Mobile Allocation, i.e. the Mobile Allocation used by the 

mobile for the assigned TBF. These radio frequency channels shall be arranged in the order of ascending ARFCN, 

except for ARFCN = 0, if included, which shall be put last. 

The first bit position in the reduced MA bitmap corresponds to the last ARFCN put in the list, the last bit position 
corresponds to the first ARFCN put in the list. Each bit position is coded: 

the corresponding radio frequency channel does not belong to the reduced MA; 

1 the corresponding radio frequency channel belongs to the reduced MA. 

MAIO_2 (6 bit field) 

This field is present when a reduced MA is used, indicating more than one frequency. 

This parameter is the binary representation of the mobile allocation index offset (MAIO) to be used on blocks using a 

reduced Mobile Allocation. 

Range to 63. 



1 2.30 MS Radio Access Capability 2 



The MS Radio Access Capability 2 information element is used to provide the radio part of the network with 
information concerning radio aspects of the mobile station. The contents may affect the manner in which the network 
handles the operation of the mobile station. 

For the indication of the radio access capabilities the following conditions shall apply (see 3GPP TS 24.008 for the 
definition of the parameters): 

- Among the three Access Technology Types GSM 900-P, GSM 900-E and GSM 900-R the MS shall include only 
one access technology type denoting the GSM 900 band it supports. 

Due to shared radio frequency channel numbers between GSM 1800 and GSM 1900, the mobile station should 
provide the relevant radio access capability for either GSM 1800 band OR GSM 1900 band, not both. 

If the alternative coding by using the Additional access technologies struct is chosen by the mobile station, the 
mobile station shall indicate its radio access capability for the serving BCCH frequency band in the first included 
Radio Access Capabilities struct if this information element is not sent in response to an Access Technologies 
Request from the network or if none of the requested Access Technology Types is supported by the mobile 
station. Otherwise, the mobile station shall include the radio access capabilities for the frequency bands it 
supports in the order of priority requested by the network as specified in sub-clause 7.1.3.2.. 

If this information element is sent during a GPRS TBF establishment, the mobile station should indicate as many 
as possible of its supported Access Technology Types. The maximum number of indicated Access Technology 
Types depends on the remaining bits left in the RLC/MAC message containing the MS Radio Access Capability 
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2 IE. The radio access capability for the serving BCCH frequency band shall be part of the indicated 
technologies, the inclusion of any other radio access capability is a mobile station implementation option. 

If this information element is sent during an EGPRS TBF establishment, the mobile station shall indicate its 
supported Access Technology Types within the ones that are requested by the network or the access technology 
of the serving BCCH frequency band, as specified by the relevant procedures. 

Table 12.30.1 : MS Radio Access Capability 2 information element 

< MS Radio Access Capability 2 IE > ::= 

< MS RA capability : < IVIS RA capability value part struct > > ; 

Table 12.30.2: MS Radio Access Capability 2 information element details 

MS RA capability 

This information element is coded as defined by the MS RA capability value part defined in the MS Radio Access 
Capability IE defined in 3GPP TS 24.008. When this information element is sent, all spare bits shall be suppressed by 
the transmitter. 



1 2.31 UTRAN FDD Target cell 

The UTRAN FDD Target cell information element contains the description of a UTRAN FDD Target cell. 

Table 12.31 .1 : UTRAN FDD Target cell information element 

< UTRAN FDD Target cell IE > ::= 
<FDD-ARFCN :bit(14)> 

< Diversity : bit > 

{ I 1 < Bandwidth_FDD : bit (3) > } 

< SCRAMBLING_CODE : bit (9) > ; 

Table 12.31 .2: UTRAN FDD Target cell information element details 

FDD_ARFCN (14 bit field) 

This information element is defined as the UARFCN in 3GPP TS 25.101. Any non-supported frequency shall not be 

considered as an error; indices of the 3G Neighbour Cell list shall be incremented accordingly. 

Diversity (1 bit field) 

This parameter indicates if diversity is applied for the cell: 

Bit 

Diversity is not applied for this cell 

1 Diversity is applied for this cell. 

Bandwidth_FDD (3 bit field) 

This information element will be used for future releases. It shall not be sent in this version of the protocol. 

When missing, this indicates the present FDD bandwidth. When present, this shall not be considered as an error; indices 

of the 3G Neighbour Cell list shall be incremented accordingly. 

Scrambling Codes (9 bit field) 

This parameter indicates the Primary Scrambling Code as defined in 3GPP TS 25.331. 
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1 2.32 UTRAN TDD Target cell 

The UTRAN TDD Target cell information element contains the description of a UTRAN TDD Target cell. 

Table 12.32.1 : UTRAN TDD Target cell information element 

< UTRAN TDD Target cell IE > ::= 
<TDD-ARFCN :bit(14)> 

< Diversity TDD : bit > 

{ I 1 < Bandwidth_TDD : bit (3) > } 

< Cell Parameter : bit (7) > 

< Sync Case TSTD : bit > ; 

Table 12.32.2: UTRAN TDD Target cell information element details 

TDD_ARFCN (14 bit field) 

This information element is defined as the UARFCN in 3GPP TS 25.102. Any non supported frequency shall not be 

considered as an error; indices of the 3G Neighbour Cell list shall be incremented accordingly. 

Bandwidth_TDD (3bit field) 

This information element refers to 3GPP TS 25.331. 

Bit 

321 

000 3.84Mcps 

001 1.28Mcps 

All other values shall not be sent. All other values shall not be interpreted as an error; indices of the 3G Neighbour Cell 
list shall be incremented accordingly (but no reporting can be performed). When missing, this indicates 3,84 Mcps. 

Diversity TDD (1 bit field) 

This parameter indicates if SCTD (see 3GPP TS 25.224) is applied for the cell: 

Bit 

SCTD is not applied for this cell 

1 SCTD is applied for this cell. 

Cell Parameter (7 bit field) 

This parameter is defined in 3GPP TS 25.223. 

Sync Case TSTD (1 bit field) 

For 3.84 Mcps TDD, this parameter is defined in 3GPP TS 25.223. 

Bit 

Sync Case 1 

1 Sync Case 2 

For 1.28 Mcps TDD, this parameter indicates if TSTD (see 3GPP TS 25.224) is applied for the cell: 
Bit 

TSTD is not applied for this cell 

1 TSTD is applied for this cell. 
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12.33 Temporary Mobile Group Identity (TMGI) 

The Temporary Mobile Group Identity (TMGI) identifies an MBMS service. The TMGI is defined in 3GPP TS 24.008. 

The Temporary Mobile Group Identity information element always contains an MBMS SERVICE ID. In case the 
TMGI originates from another PLMN than the local one, the MCC (Mobile Country Code) and the MNC (Mobile 
Network Code) of that originating PLMN shall also be present. 

Table 12.33.1: 7MG/ information element 



<TMGI IE>::= 




{0 


-- without MCC and MNC parameters 


< MBMS SERVICE ID : bit (24) > 




M 


- with MCC and MNC parameters 


< MBMS SERVICE ID : bit (24) > 




< MCC: bit (12) > 




<MNC:bit(12)>} ; 





Table 12.33.2: 7MG/ information element details 



MBMS SERVICE ID (24 bit field) 

This field contains the identity of the MBMS service. The MBMS SERVICE ID is unique within a PLMN. 

MCC (12 bit field) 

This field contains the Mobile Country Code of the originating PLMN. 

MNC (12 bit field) 

This field contains the Mobile Network Code of the originating PLMN. 



1 2.34 MBMS Bearer Identity 

The MBMS Bearer Identity uniquely identifies an MBMS radio bearer on a PDCH. 

Table 12.34.1 : MBMS Bearer Identity information element details 



MBMS Bearer Identity (1-5 bit field) 

The MBMS Bearer Identity field assigns a TFI value, or a subset of a TFI value, which identifies an MBMS radio 
bearer on a PDCH. In case only a subset of a TFI value is assigned for the MBMS radio bearer, that subset corresponds 
to the most significant bit(s) of the TFI field. The length of this field is defined by the value of the Length of MBMS 
Bearer Identity field, whose value is defined by a 3 bit field (range 1 to 5). 

The MBMS Bearer Identity field is encoded as a binary number. 

Range: 

1 bit field to 1 

2 bit field to 3 

3 bit field to 7 

4 bit field Otol5 

5 bit field Oto31 



12.35 MSJD 

The MSJD uniquely addresses a mobile station on an MBMS radio bearer with an assigned uplink feedback channel. 

Table 12.35.1 : MS ID information element details 



MS_ID (1-4 bit field) 
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An MS_ID is assigned to a mobile station for a given MBMS radio bearer with an uplink feedback channel. The length 
of the MS_ID field is defined by the value, increased by 1, of the Length Indicator ofMS_ID field, whose value is 
defined by a 2 bit field (range 1 to 4). The sum of the length of the MBMS Bearer Identity field and of the length of the 
MS_ID field is equal to 5, i.e. the length of the TFI field. 

The MS_ID field is encoded as a binary number. 

Range: 

1 bit field to 1 

2 bit field to 3 

3 bit field to 7 

4 bit field to 15 



12.36 MBMS Channel Parameters 

The MBMS Channel Parameters contain various parameters applicable to one or more MBMS sessions. 

Table 12.36.1 : MBMS Channel Parameters information element 

< MBMS Channel Parameters IE >::= 

{ -- counting is off 

{ I 1 < MBMS p-t-m channel description : < MBMS p-t-m channel description IE > > 
< MBMS Session Parameters List : < MBMS Session Parameters List IE » } 
I 1 -- counting is on 
{ I 1 < MPRACH description : < MPRACH description IE > > } }; 

Table 12.36.2: MBMS Channel Parameters information element details 

MBMS p-t-m channel description 

This information element contains the MBMS p-t-m channel description of one or more MBMS sessions. This 
information element is defined in sub-clause 12.37. 

MBMS Session Parameters List 

This information element contains a list of MBMS Session Parameters to use on the MBMS p-t-m channel provided in 
the MBMS p-t-m channel description. Each entry in this list is associated with a notified MBMS session as identified in 
the MBMS Sessions List for this MBMS p-t-m channel. The n-th entry in the MBMS Session Parameters list 
corresponds to the n-th notified MBMS Session in the MBMS Sessions List. This information element is defined in 
sub-clause 12.40. 

MPRACH description 

This information element contains the description of the MPRACH on which the MBMS packet access procedure is 
initiated (see sub-clause 7.7.1). This information element is defined in sub-clause 12.38. 



12.37 MBMS p-t-m channel description 

The MBMS p-t-m channel description contains the p-t-m channel description for one or more MBMS sessions. 
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Table 12.37.1 : MBMS p-t-m channel description information element 



< MBMS p-t-m channel description IE > :: = 

{ I 1 < Frequency Parameters : < Frequency Parameters IE > > } 
< DL_TIMESLOT_ALLOCATION : bit (8) >; 



Table 12.37.2: MBMS p-t-m channel description information element details 



Frequency Parameters 

If this information element is not present, the same frequency as for the PCCCH shall be used. This information 
element is defined in sub-clause 12.8. 

DL_TIMESLOT_ALLOCATION (8 bit field) 
This field is defined in sub-clause 12.18. 



1 2.38 MPRACH description 



The MPRACH description contains the MPRACH parameters to be used if MPRACH is indicated in an MBMS 
notification. 

Table 12.38.1: MPRACH description information element 



< MPRACH description IE > :: = 








{ 1 1 < Frequency Parameters : < 


Frequency Parameters IE > > } 




< MPRACH TIMESLOT NUMBER 


bit (3) > 






< USF : bit (3) > 








{ 1 1 < MPRACH Control Parameters : 


< MPRACH Control Parameters IE 


>>}; 



Table 12.38.2: MPRACH description information element details 



Frequency Parameters 

If this information element is not present, the same frequency as for the PCCCH shall be used. This information 
element is defined in sub-clause 12.8. 

MPRACH_TIMESLOT NUMBER (3 bit field) 

This field identifies the timeslot number of the PDCH where the MPRACH is located. 

USF (3 bit field) 

This field identifies the USF value that identifies the MPRACH on the defined PDCH. 

MPRACH Control Parameters 

This information element, if present, defines the access control parameters to be used on the MPRACH. This 
information element is defined in sub-clause 12.41. 



1 2.39 IVIBIVIS Sessions List 

The MBMS Session List contains a list of MBMS sessions, identified by their TMGI, and if available MBMS Session 
Identity. 

Table 12.39.1 : MBMS Sessions List information element 



< MBMS Session List IE > ::= 
{1 <TMGI :<TMGI IE » 

{ |1 < MBMS Session Identity : bit (8) > } } ** 0; 
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Table 12.39.2: MBMS Sessions List information element 

TMGI 

This information element contains the Temporary Mobile Group Identity of an MBMS service. This information 
element is encoded as defined in sub-clause 12.33. 

MBMS Session Identity (8 bit field) 

This field contains the MBMS Session Identity of the concerned MBMS session. 



12.40 MBMS Session Parameters List 

The MBMS Session Parameters List contains a list of MBMS Bearer IDs, Estimated Session Durations, MBMS Radio 
Bearer Starting Times, EGPRS Windows Sizes and NPM Transfer Times. 

Table 12.40.1 : MBMS Session Parameters List information element 

< MBMS Session Parameters List IE > ::= 

{ 1 < Length of MBMS Bearer Identity : bit (3) > -- Configurations '000', '110' and '1 1 1 ' are reserved 

< MBMS Bearer Identity : bit (val (Lengtii of MBMS Bearer Identity)) > 

< Estimated Session Duration : bit (8) > 

{ I 1 < MBMS Radio Bearer Starting Time : bit (1 6) > } 
{ I 1 < EGPRS Window Size : < EGPRS Window Size IE » } 
{ I 1 < NPM Transfer Time : bit (5) > } } " 0; 

Table 12.40.2: MBMS Session Parameters List information element details 

Length of MBMS Bearer Identity (3 bit field) 

This field indicates the length of the MBMS Bearer Identity for the concerned MBMS session. Any value from 1 to 5 

inclusive is allowed. All other values are reserved. 

MBMS Bearer Identity (1-5 bit field) 

This field contains the Bearer identity for the concerned MBMS session. This information element is defined in sub- 
clause 12.34. 

Estimated Session Duration (8 bit field) 

This field contains an estimation of either the duration for the concerned MBMS session or, if the MBMS session is 

ongoing, the remaining duration for the concerned MBMS session. This information element is defined in sub-clause 

12.44. 

MBMS Radio Bearer Starting Time (16 bit field) 

This field contains a starting time that indicates the frame number from which the data transfer on the assigned MBMS 
radio bearer may start for the concerned MBMS session. The MBMS Radio Bearer Starting Time is encoded as the 
value part of the type 3 information element Starting Time in 3GPP TS 44.018. 

EGPRS Window Size 

This information element defines the EGPRS Window Size for the concerned MBMS session and is defined in sub- 
clause 12.5.2. 

NPM Transfer Time (5 bit field) 

This field defines the NPM Transfer Time limitation for the concerned MBMS session and is defined in sub-clause 

12.45a. 
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12.41 MPRACH Control Parameters 

The purpose of the MPRACH Control Parameters information element is to provide parameters used to control the 
MPRACH utihzation. 

Table 12.41 .1 : MPRACH Control Parameters information elements 



< MPRACH Control Parameters IE > 


::= 


{01 


1 < ACC CONTR CLASS : bit (1 6) > } 


{01 


1<MAX RETRANS : bit (2) 


>} 


<S 


bit (4) > 




{01 


1 < TX INT : bit (4) > } 




{01 


1 < PERSISTENCE LEVEL 


: bit (4) > } ; 



Table 12.41.2: MPRACH Control Parameters information element details 



TXJNT (4 bit field) 

Number of slots to spread transmission of the random access. This information element is encoded as defined in sub- 
clause 12.14. 

S (4 bit field) 

S is a parameter used for calculation of the minimum number of slots between two successive Channel request 

messages. This information element is encoded as defined in sub-clause 12.14. 

MAX_RETRANS (2 bit field) 

Indicates the maximum number of retransmissions allowed. This information element is encoded as defined in sub- 
clause 12.14. 

PERSISTENCE_LEVEL (4 bit field) 

The PERISTENCE_LEVEL field indicates the values of the access persistence level. This information element is 

encoded as defined in sub-clause 12.14. 

ACC_CONTR_CLASS ( 16 bit field) 

Access Control Class N (bit 1-16) (see octet 3 and 4 of the RACH Control Parameters IE in 3GPP TS 44.018) . This 

information element is encoded as defined in sub-clause 12.14. 



12.42 PS Handover Radio Resources 

This information element is the Radio Network Part of the PS Handover to A/Gb mode payload IE. 
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Table 12.42.1 : PS Handover Radio Resources information element 

< PS Handover Radio Resources IE > ::= 

{ I 1 < Handover Reference : bit (8) > } 
<ARFCN:bit{10)> 

< SI : bit (2) > 
<NCI :bit(1)> 

< BSIC : bit (6) > 

{ I 1 < CCN_ACTIVE : bit (1 ) > } 

{ I 1 < 3G_CCN_ACTIVE : bit (1 ) > } 

{ I 1 < CCN Support Description : < CCN Support Description struct » } 

< Frequency Parameters : < Frequency Parameters IE > > 

< NETWORK_CONTROL_ORDER : bit (2) > 

{ I 1 < Global Packet Timing Advance : < Global Packet Timing Advance IE > > 

{ I 1 < Packet Extended Timing Advance : bit (2) > } } -- Only used in uplink 

< EXTENDED_DYNAMIC_ALLOCATION : bit (1 ) > -- Only used in uplink 

<RLC_RESET:bit(1)> 

{ I 1 < PO : bit (4) > 

<PR_M0DE:bit(1)>} 

{ I 1 < Uplink Control TImeslot : bit (3) > } 

{ < GPRS mode : < GPRS mode struct > > 
I 1 < EGPRS mode : < EGPRS mode struct > > } ; 

< CCN Support Description struct > ::= 

< NumberCells : bit (7) > 

{ CCN_SUPPORTED : bit } * (val(Number_Cells)) ; 

< GPRS mode struct > ::= 

-- Uplinl< TBFs 

{ { I 1 < CHANNEL_CODING_COMMAND : bit (2) > } 

{ I 1 < Global Timeslot description : < Timeslot description struct > > 
{ 1 < Uplink Assignment : < Uplinl< TBF Assignment struct > > } ** } 

- Downlinl< TBFs 

{ 1 < Downlink Assignment : < Downlinl< Assignment struct > > } ** } ; 

< EGPRS mode struct > ::= 

-- Uplinl< TBFs 

{ { I 1 < EGPRS Window Size : < EGPRS Window Size IE > > } 

{ I 1 < EGPRS Channel Coding Command : < EGPRS Modulation and Coding Scheme IE > > } 

{ I 1 < BEP_PERI0D2 : bit{4) > } 

{ I 1 < Global Timeslot description : < Timeslot description struct > > 
{ 1 < Uplink Assignment : < Uplinl< TBF Assignment struct > > } ** } } 

- Downlinl< TBFs 
{0|1 

{ I 1 { I 1 < EGPRS Window Size : < EGPRS Window Size IE > > } 
< LINK_QUALITY_MEASUREMENT_MODE : bit (2) > 
{ I 1 < BEP_PERI0D2 : bit(4) > } } 
{ 1 < Downlink Assignment : < Downlinl< Assignment struct > > } ** } ; 
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< Uplink TBF Assignment struct > ::= 


- Recursive for multiple TBFs 


{0 1 1 < PFI : bit (7) > } 




<RLC_M0DE:bit(1)> 




< TFI Assignment : bit (5) > 




{ 1 1 < CHANNEL_CODING_COMMAND : bit (2) > } 


{ 1 < EGPRS Channel Coding Command : 


< EGPRS Modulation and Coding Scheme IE > > } 


{ 1 1 < EGPRS Window Size : < EGPRS Window Size IE > > } 


< USF GRANULARITY : bit (1) > 




{0 


-- Ttie timeslots assigned to the TBF are all the timeslots assigned 




- in the Global Timeslot description 


1 1 < TBF_TIMESLOT_ALLOCATION : bit (N) : 


> } - The timeslots assigned to the TBF are a subset of all the 




- timeslots assigned in the Global Timeslot description. Where 




- N Is the number of timeslots assigned to the MS in the Global 




- Timeslot description 


{ < USF ALLOCATION : bit (3) > 


- The same USF is valid on all timeslots assigned to the TBF 


M 


- Different USF(s) assigned 


< USF_ALLOCATION : bit (3) > 


-- USF assignment on the lowest numbered timeslot 




-- assigned to the TBF 


{ 1 1 < USF_ALLOCATION : bit (3) > } 


" (M-1 ) } ; -- USFs on subsequent timeslots assigned to the TBF: 




- A'O' (respectively a '1 ' followed by a USF value) 




-- means same (respectively different) USF value as the 




-- USF on the next lower numbered timeslot assigned to 




-- the TBF. Where M is the amount of timeslots assigned 




- to the TBF in the TBF_TIMESLOT_ALLOCATION if 




-- present, else in the Global Timeslot description. 


< Downlinl< Assignment struct > ::= -- Recursive for multiple TBFs 


< TIMESLOT_ALLOCATION : bit (8) > 




{ < Downlinl< TBF assignment : < Downlinl< TBF 


assignment struct > > } ; 


< Downlinl< TBF assignment struct > :: = 




{ 1 1 < PFI : bit (7) > }- 




<RLC_M0DE:bit(1)> 




< TFI Assignment : bit (5) > 




< CONTROL ACK:bit(1)> 




{ 1 1 < EGPRS Window Size : < EGPRS Window Size IE > > } ; 


< Timeslot description struct > ::= 




{0 


-- without power control params 


< MS TIMESLOT ALLOCATION : bit (8) > 




M 


- with power control params 


< ALPHA : bit (4) > 




{ |1 < GAMMA TNO : bit (5) > } 




{ |1 < GAMMA TNI : bit (5) > } 




{ |1 < GAMMA TN2 : bit (5) > } 




{ |1 < GAMMA TN3 : bit (5) > } 




{ 1 1 < GAMMA TN4 : bit (5) > } 




{ |1 < GAMMA TN5 : bit (5) > } 




{ 1 1 < GAMMA TN6 : bit (5) > } 




{ 1 1 < GAMMA TN7 : bit (5) > } } ; 





Table 12.42.2: PS Handover Radio Resources information element details 



Handover Reference (8 bit field) 

This field contains the reference value to be used when performing PS Handover. The field is encoded as the contents 

of the Handover Reference information element as defined in 3GPP TS 44.018. 
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SI (2 bit field) 

The Synchronization Indication (SI) field indicates which type of PS Handover is to be performed. 

Bit 

2 1 

Non-synchronized 

1 Synchronized 

1 Pre-synchronised 
1 1 reserved 

NCI (1 bit field) 

The Normal Cell Indication (NCI) field indicates how the MS shall behave in case of out of range timing advance 

values. 

Bit 
1 

Out of range timing advance is ignored 

1 Out of range timing advance shall trigger a handover failure procedure. 

ARFCN (10 bit field) 

This field contains the BCCH frequency of the new cell. This field is encoded as the ARFCN defined in 3GPP TS 

44.018. 

Range: to 1023. 

BSIC (6 bit field) 

This field contains the BSIC of the new cell. The BSIC field is coded as the "Base Station Identity Code" defined in 

3GPP TS 23.003. 

CCN_ACTIVE (1 bit field) 

For description and encoding, see the Packet Cell Change Order message. 

3G_CCN_ACTIVE (1 bit field) 

For description and encoding, see the Packet Cell Change Order message. 

CCN Support Description 

CCN_SUPPORTED (1 bit field) 

For description and encoding, see the Packet Cell Change Order message. 

Frequency Parameters 

This information element is defined in sub-clause 12.8. 

EXTENDED_DYNAMIC_ALLOCATION (1 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

NETWORK_CONTROL_ORDER (2 bit field) 

For description and encoding, see the Packet Measurement Order message. 

PO (4 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

PR_MODE (1 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

Global Packet Timing Advance 

This information element is defined in sub-clause 12.12a 
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RLC_RESET (1 bit field) 

This information element indicates whether or not all RLC entities used to support the given TBFs in the old cell shall 

be reset to support the TBFs allocated for the corresponding PFCs in the new cell: 

RLC is not reset (the RLC state machines are maintained across PS handover) 

1 RLC is reset (the RLC state machines are not maintained across PS handover) 

If this field is set to '1', then after successful completion of the PS Handover procedure, the mobile shall consider all 
TBFs which were ongoing when the PS Handover Command message was received to have been implicitly released. 

Packet Extended Timing Advance (2 bit field) 
This field is defined in sub-clause 12.12b. 

Uplink Control Timeslot (3 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

CHANNEL_CODING_COMMAND (2 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

EGPRS Window Size 

This information element is defined in sub-clause 12.5.2. 

EGPRS Modulation and Coding Scheme 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

BEP_PERIOD2 (4 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

LINK_QUALITY_MEASUREMENT_MODE (2 bit field) 

For description and encoding, see the Multiple TBF Downlink Assignment message. 

PFI (7 bit field) 

This field shall only be included for TBFs if both the network and the mobile station support multiple TBFs. This field 
contains the PFI parameter identifying a Packet Flow Context. The PFI parameter is encoded as the contents of the PFI 
information element as defined in 3GPP TS 44.018. 

TFI Assignment (5 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

USF_GRANULARITY (1 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

TBF_TIMESLOT_ALLOCATION (N bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

USF_ALLOCATION (3 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 

RLC_MODE (1 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message or the Multiple TBF Downlink 
Assignment message. If the RLC_RESET field indicates that any given RLC entity is not reset across PS handover 
then the mobile station shall ignore this field and use the same RLC mode that was used for the corresponding PFC in 
the old cell. 

CONTROL_ACK (1 bit field) 

If the RLC_RESET field indicates that RLC entities are reset, this field shall be set to '0'. 

If multiple TBFs are supported by both network and mobile station and the RLC_RESET field indicates that RLC 

entities are not reset, this field shall be coded as specified for the Multiple TBF Downlink Assignment message. 

If either the network or the mobile station does not support the multiple TBF feature and the RLC_RESET field 

indicates that RLC entities are not reset, this field shall be set to '1' if the network establishes a new downlink TBF for 

the mobile station whose timer T3192 is running. Otherwise this field shall be set to '0'. 

TIMESLOT_ALLOCATION (8 bit field) 

For description and encoding, see the Multiple TBF Downlink Assignment message. 
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MS_TIMESLOT_ALLOCATION (8 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. As the explicit power control 
parameters are omitted for the allocated timeslots in the new cell, the mobile station shall use the default values (see 
3GPP TS 45.008) for the power control parameters. 

ALPHA (4 bit field) 

For encoding and description see the Global Power Control Parameters IE. 

GAMMA_TN (5 bit field) 

For description and encoding, see the Multiple TBF Uplink Assignment message. 



1 2.43 NAS Container for PS Handover 

The purpose of the NAS Container for PS Handover information element (see Note 1) is to indicate the layer 3 
information to be applied by the mobile station upon successful completion of PS handover to A/Gb mode. When 
included in a PS HANDOVER COMMAND message this IE and the PS Handover Radio Resources IE (see sub-clause 
12.42) shall have a combined length that does not exceed 175 octets. 

Table 12.43.1 : NAS Container for PS Handover information element 

< NAS Container for PS Handover IE > ::= 

< NAS_CONTAINER_LENGTH : bit (7) > 
< NAS_CONTAINER_DATA : octet (val(NAS_CONTAINER_LENGTH)) > ; 



Table 12.43.2: NAS Container for PS Handover information element details 

NAS_CONTAINER_DATA (N octet field) 

This contents of this information element is identical to the value part of the NAS Container for PS Handover 
information element described in 3GPP TS 24.008 where N is the length of the value part of the NAS Container for PS 
Handover information element. 



12.44 Estimated Session Duration 

The Estimated Session Duration gives an estimation of the (remaining) duration for the MEMS session. The initial 
value is derived from the payload in the MBMS Session Duration IE (see 3GPP TS 48.018), rounded up to the next 
higher value that can be signalled with the coding provided in Table 12.44.1. Any subsequent value for the remaining 
duration of the MBMS session is derived from the initial value, unless an up-to-date value is available in the MBMS 
Session Duration IE. 

Table 12.44.1 : Estimated Session Duration information element details 

Estimated Session Duration (8 bit field) 

The Estimated Session Duration information element is coded as follows: 

bit 
87654321 

00000000 5 seconds 

00000001 10 seconds 
... in 5s step 
10 11 1 minute 

110 1 minute 10 seconds 

... in 10s step 

10 11 5 minutes 

10 10 5 minutes 30 seconds 

in 30s step 
10 110 1 10 minutes 
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00101110 

1011111 

01 100000 

1 000 1111 
10010000 

1010001 1 
10100100 

10111111 
1 1000000 

1110 1111 
1 1 1 10000 

11110101 
11110110 

11111101 
11111110 

11111111 



11 minutes 

in Im step 

1 hour 

1 hour 5 minutes 

in 5m step 

5 hours 

5 hours 15 minutes 

in 15m step 

10 hours 

10 hours 30 minutes 

in 30m step 

1 day 

I day 3 hours 
in 3h step 

7 days 

7 days 12 hours 
in 12h step 
10 days 

II days 

in 1 day step 
ISdays 
19 days 
>19 days 



12.45 MBMS In-band Signalling Indicator 

The MBMS In-band Signalling Indicator indicates whether the network sends system information messages and (for 
mobile stations with an assigned MS_ID on that MBMS radio bearer) paging messages on the PACCH. 

Table 12.45.1 : MBMS In-band Signalling Indicator information elements 

< MBMS In-band Signalling Indicator IE > ::= 

< MBMS In-band Signalling Indicator: bit (1) >; 



Table 12.45.2: MBMS In-band Signalling Indicator information element details 

MBMS In-band Signalling Indicator (1 bit field) 

The MBMS In-band Signalling Indicator information element is coded as follows: 

Bit 

System information and paging messages are not sent on the PACCH of the MBMS radio bearer. 

1 System information and paging messages are sent on the PACCH of the MBMS radio bearer. 



12.45a NPM Transfer Time 

This information element defines the NPM Transfer Time limitation in case of RLC non-persistent mode and is derived 
from the Transfer Delay IE defined in 3GPP TS 24.008. 
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Table 12.45a.1 : NPM Transfer Time Information Elements details 



bit 
54321 


NPM Transfer Time (in ms) 


00000 


30 


00001 


40 


00010 


50 


00011 


60 


00 100 


70 


00 101 


80 


00110 


90 


00111 


100 


01000 


125 


01001 


150 


01010 


175 


01011 


200 


01100 


225 


01101 


250 


01110 


275 


1111 


300 


10000 


400 


10001 


500 


10010 


600 


10011 


700 


10 100 


800 


10 101 


900 


10 110 


1000 


10 111 


1500 


11000 


2000 


11001 


2500 


11010 


3000 


11011 


3500 


11100 


4000 


11101 


4500 


11110 


5000 


11111 


Reserved 



12.45b RRC Container 

The RRC Container is used to contain an RRC message (e.g. HANDOVER TO UTRAN COMMAND) as defined in 
3GPPTS 25.331 [20]. 

Table 1 2.45b. 1: RRC Container information element 

< RRC Container IE > ::= 

< RRC_CONTAINER_LENGTH : bit (8) > 

< RRC_CONTAINER_DATA : octet (val(RRC_CONTAINER_LENGTH)) > 

< padding bits > ; 
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Table 12.45b.2: RRC Container information element details 

RRC_CONTAINER_LENGTH (8 bit field) 

This field indicates the number of octets in the RRC_CONTAINER_DATA. 

bit 

87654321 

00000000 reserved for future use; 

1 RRC_CONTAINER_DATA length = 1 octet; 

10 RRC_CONTAINER_DATA length = 2 octets; 

11111111 RRC_CONTAINER_DATA length = 255 octets; 

RRC_CONTAINER_DATA (N octet field) 

This field contains an RRC nnessage as specified in 3GPP TS 25.331 [20]. 



13 Timers and counters 



The tables in sub-clause 13.1 and 13.2 specify the timers used in RLC/MAC protocol signalling. The denotation of 
columns is defined as follows: 

timer ::= name of the timer; 

started ::= under which conditions the timer is started; 

stopped ::= under which conditions the timer is stopped; 

action at expiry ::= which actions the GPRS entity shall perform at expiry; 

value ;;= the duration between setting the timer and expiry of the timer ("s" denotes 

"second(s)" "xx - yy" means that any value between xx and yy is permitted). 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 



408 



ETSI TS 144 060 V6.28.0 (2010-03) 



13.1 Timers on the Mobile Station side 

For each timer, it is shown whether one timer instance is needed per MS, per TBF/MBMS radio bearer, per MS_ID or per RLC/MAC control message. 

Table 13.1.1 : Specification of timers used in GPRS on the IVIobile Station side 



timer 


started 


stopped 


action at expiry 


value 


131 58 

(per 
MS) 


Started when ordered by a 
NETWORK_CONTROL_ORDER and then 
restarted each time a Network Controlled (NC) 
Measurement is performed in MM Ready state 
and in packet idle or packet transfer mode in 
A/Gb mode and in RRC-Cell_Shared state and 
MAC-ldle or MAC-Shared state in lu mode. 


See 3GPP TS 45.008 


Restart the timer, perform the measurement and 
send a NC Measurement report. The timer shall be 
restarted with either of the parameters 
NC_REPORTING_PERIOD_l when in packet idle 
mode or MAC-ldle state or with the parameter 
NC_REPORTING_PERIOD_T when in packet 
transfer mode or MAC-Shared state 


Defined by the 
parameter or by a 
random value (see 
3GPP TS 45.008) 


131 62 

(per 
MS) 


On receipt of a PACKET QUEUING 
NOTIFICATION 


On receipt of a PACKET UPLINK ASSIGNMENT 


Abort Packet access procedure; indicate Packet 
access failure to upper layers and Return to 
packet idle mode or MAC-ldle state listening to its 
paging subchannel 


5s 


131 64 
(per 
TBF) 


On receipt of a 

PACKET UPLINK ASSIGNMENT or 

MULTIPLE TBF UPLINK ASSIGNMENT 

message. A separate instance of T31 64 is 

started for each TBF for which resources were 

assigned. 


At sending of the first RLC/MAC block 


See sub-clause 7.1 .4. (A/Gb mode) or 
3GPP TS 44.160 sub-clause 7.2.5 (lu mode). 


5s 


T3166 

(per 
MS) 


At sending of the first RLC/MAC block at one 
phase access 


On receipt of a PACKET UPLINK ACK/NACK 


Immediately stop transmitting on the assigned 
TBF; a TBF establishment failure has occurred or 
the contention resolution procedures has failed 


5s 


T3168 
(per 
TBF) 


At sending the PACKET RESOURCE 
REOUEST message, (Extended) Channel 
Request Description IE in 
PACKET DOWNLINK ACK/NACK or the 
PACKET CONTROL ACKNOWLEDGEMENT 
message requesting new TBF. A separate 
instance of T31 68 is started for each TBF for 
which resources were requested. 


On receipt of a PACKET UPLINK ASSIGNMENT, 
MULTIPLE TBF UPLINK ASSIGNMENT, PACKET 
TIMESLOT RECONFIGURE or a MULTIPLE TBF 
TIMESLOT RECONFIGURE message that assigns 
resources to an uplink TBF for which T31 68 is 
running. On receipt of a PACKET ACCESS 
REJECT message that rejects one or more uplink 
TBFs for which T31 68 is running. 


Reinitiate the packet access procedure or 
retransmit the PACKET RESOURCE REQUEST 
or PACKET DOWNLINK ACK/NACK for the TBFs 
that have not been assigned resources. 


Set to 2 times the 
value of T31 68 
sent as part of 
system broadcast 
information if the 
total number of 
TBFs requested is 
greater than 1. 
Otherwise, it shall 
be set to the value 
ofT3168sentas 
part of system 
broadcast 
information. 
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timer 


started 


stopped 


action at expiry 


value 


T3170 
(per 
MS) 


After having made M + 1 attempts to send a 
PACKET CHANNEL REQUEST or EGPRS 
PACKET CHANNEL REQUEST or MPRACH 
PACKET CHANNEL REQUEST message, or 
on receipt of a PACKET ACCESS REJECT 
message. 


On receipt of a PACKET UPLINK ASSIGNMENT 
or PACKET QUEUING NQTIFICATIQN message. 


Abort Packet access procedure; indicate a random 
access failure to upper layer and return to packet 
idle mode or MAC-ldle state. 


Defined by 
parameters 
TX_INT and S 


T3172 
(per 
TBF) 


Qn receipt of a PACKET ACCESS REJECT 
message an instance of T3172 is started for 
eacli of tlie TBFs tliat have been rejected. 


On receipt of a PACKET UPLINK ASSIGNMENT 
message or MULTIPLE TBF UPLINK 
ASSIGNMENT that assigns resources to the TBF 
for which T31 72 is running. 


Packet Access in the cell no longer prohibited 


assigned in 
message 


T3174 
(per 
MS) 


Qn receipt of a PACKET CELL CHANGE 
QRDER message 


On the successful completion or the occurrence of 
an abnormal condition in the network controlled cell 
reselection procedure 


Return to old cell, perform cell update (or other 
GMM specific procedure) and send PACKET 
CELL CHANGE FAILURE 


15s 


T3176 
(per 
MS) 


Expiry of T3174 or other abnormal condition in 
the networl< controlled cell reselection 
procedure 


After sending of PACKET CELL CHANGE 
FAILURE message 


Stop handling of abnormal condition in the network 
controlled cell reselection procedure. 


15s 


T3180 
(per 
TBF) 


When transmitting an RLC/MAC block to the 
networl< an instance of T3180 is started for the 
TBF for which the blocl< was intended. It is also 
started for each uplink TBF allocated by the PS 
HANDQVER CQMMAND message upon 
successful completion of the PS handover from 
lu mode to A/Gb mode (see sub-clause 8.10.4). 


When detecting an assigned USE value on 
assigned PDCH 


Abnormal release with access retry may be 
performed under certain conditions (see sub- 
clause 8.1.1.1) 


5s 


T3182 
(per 
TBF) 


After sending the last data block (with CV = 0), 
or upon detecting a transmit window stall 
condition an instance of T3182 is started for the 
TBF for which the condition has occurred. 


On receipt of the PACKET UPLINK ACK/NACK 
message 


Abnormal release with access retry may be 
performed under certain conditions (see sub- 
clauses 9.3.2.3 and 9.3.3.3) 


5s 
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timer 


Started 


stopped 


action at expiry 


value 


T3184 
(per 
TBF) 


On receipt of a PACKET UPLINK ACK/NACK 
message (in exclusive allocation) 


On receipt of PACKET UPLINK ACK/NACK 

message 

(T3184 is also restarted) 


Abnormal release with access retry may be 
performed under certain conditions (see sub- 
clause 8.1.1. 3a.2). 


5s 


T3186 
(per 
MS) 


When packet access procedure is started 


Either stopped when receiving any message from 
the network in response to the PACKET CHANNEL 
REOUEST message or after M-i-1 attempts to send 
PACKET CHANNEL REQUEST messages on the 
PRACH channel or 

stopped when receiving any message from the 
network in response to the MPRACH PACKET 
CHANNEL REQUEST message or after M-i-1 
attempts to send MPRACH PACKET CHANNEL 
REQUEST messages on the uplink PDCH channel 


Abort packet access procedure; indicate random 
access failure to upper layers and return to packet 
idle mode or MAC-ldle state. 


5s 


T3188 


When a mobile station that supports multiple 
TBF procedures requests two or more uplink 
TBFs in a Packet Resource Request message 
during a two-phase access. 


When a mobile station that supports multiple TBF 
procedures receives a MULTIPLE TBF UPLINK 
ASSIGNMENT message. 


A mobile station that supports multiple TBF 
procedures considers its' two-phase access to 
have failed 


Set to the value of 
T3168 included as 
part of system 
broadcast 
information. 


T3190 
(per 
TBF/ 

MBMS 
radio 

bearer) 


At reception of a downlink assignment 
message an instance of T3190 is started for 
each TBF/MBMS radio bearer that has been 
assigned resources. It is also started for each 
downlink TBF allocated by the PS HANDOVER 
COMMAND message upon successful 
completion of the PS handover from lu mode to 
A/Gb mode (see sub-clause 8.10.4). 


Restarted on receipt of data on the TBF/MBMS 
radio bearer 


Abnormal release without retry may be performed 
under certain conditions (see sub-clauses 8.1 .2.1 
and 8.1.2.4). 

The MBMS packet access procedure may be 
initiated as specified in sub-clause 7.7.1 . 


5s 


T3192 
(per 
TBF) 


At sending the 

PACKET DOWNLINK ACK/NACK with the 
Final Ack lndicator=1 , or at sending the 
PACKET CONTROL ACK as a response to 
final RLC data block in unacknowledged mode. 


Restarted at sending the 
PACKET DOWNLINK ACK/NACK with the Final 
Ack lndicator=1 , or at sending the PACKET 
CONTROL ACK as a response to final RLC data 
block in unacknowledged mode. 

Stopped at the reception of a 
PACKET DOWNLINK ASSIGNMENT, MULTIPLE 
TBF DOWNLINK ASSIGNMENT, PACKET 
TIMESLOT RECONFIGURE, MULTIPLE TBF 
TIMESLOT RECONFIGURE or PACKET CS 
RELEASE INDICATION message that assigns 
resources to the TBF for which T3192 was started.. 


If the mobile station is in packet transfer mode or 
MAC-Shared state it shall release the resources, 
stop monitoring the PDCHs, and begin to monitor 
the paging channel if there are no other ongoing 
TBFs. The mobile station in dual transfer mode 
respectively MAC-DTM state shall return to 
dedicated mode or MAC-Dedicated state, (see 
sub-clauses 9.3.2.6 and 9.3.3.5). 


assigned in 
system 
information 


T3194 
(per 
TBF) 


At the sending of a RLC data block on a radio 
block that has been stolen (i.e. intended for a 
different radio bearer). See 3GPP TS 44.160 


On receipt of the USF for the radio bearer for which 
the radio block was stolen. 


Restart the timer unless it has expired four times, 
in which case a link failure is reported to the RRC 
layer. 


200 ms 


T3196 


When the RR connection request is received 
from the upper layer. 


Upon receipt of the PACKET CS COMMAND 
message. 


Release of all ongoing TBFs and start RR 
connection establishment as specified in 3GPP TS 
44.018. 


1.5 s 
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timer 


started 


stopped 


action at expiry 


value 


T3200 
(per 

RLC/M 
AC 

control 

messa 

ge) 


On receipt of an RLC/MAC control block 
containing a segment of an RLC/MAC control 
message 


On receipt of an RLC/MAC control block containing 
a segment of an RLC/MAC control message such 
that the mobile station now has the complete 
control message 


Discard and ignore all segments of the partially 
received RLC/MAC control message 


see sub-clause 
9.1.11b 


T3204 
(per 
MS) 


The first attempt to send a PACKET CHANNEL 
REQUEST during a packet access procedure. 
The PACKET CHANNEL REQUEST was 
attempted indicating 'Single block without TBF 
establishment' and the purpose of the packet 
access procedure is to send a PACKET 
PAUSE message. 


Upon receipt of a 

PACKET UPLINK ASSIGHNMENT. 


The packet pause procedure (sub-clause 7.6) is 
aborted (A/Gb mode only). 


1 s 


T3206 
(per 
MS) 


When entering CCN mode 


When the PACKET CELL CHANGE 
NOTIFICATION message is transmitted or when 
CCN is no longer enabled. 


Leave CCN mode and continue according to 
current NC mode 


400 ms 


T3208 
(per 
MS) 


When the PACKET CELL CHANGE 
NQTIFICATION message is transmitted for the 
first time 


Upon receipt of a PACKET CELL CHANGE 
CONTINUE or a PACKET CELL CHANGE ORDER 
message or when CCN is no longer enabled.. 


Leave CCN mode and continue according to 
current NC mode 


0,96 s 


T3210 
(per 
MS) 


When the PACKET CELL CHANGE 
NQTIFICATION message is transmitted for the 
first time 


Upon receipt of a PACKET NEIGHBOUR CELL 
DATA message, or a PACKET CELL CHANGE 
CONTINUE message or a PACKET CELL 
CHANGE ORDER message or when CCN is no 
longer enabled. 


Retransmit the PACKET CELL CHANGE 
NQTIFICATION message at the first uplink 
opportunity. 


0,3 s 


T3214 


When the MBMS SERVICE REQUEST 
message is transmitted or when receiving 
MBMS notification, for an MBMS session the 
mobile station is required to receive, with no 
MBMS p-t-m channel description and indicating 
that no counting shall be performed. 


Upon receipt of the MBMS ASSIGNMENT 
message addressing the same session that started 
this timer or any other procedure on (P)CCCH not 
related to MBMS is triggered or a notification is 
received for a higher priority session. 


Mobile station in packet idle mode or MAC-ldle 
state: Return to DRX mode. 

Mobile station in broadcast/multicast receive 
mode: Remain in broadcast/multicast receive 
mode 


60s 


T3216 
(per 
MS) 


Upon transmission of the PS HANDOVER 
ACCESS message (see sub-clause 
8.10.4.4.4). 


Upon receipt of the PACKET PHYSICAL 
INFORMATION message 


The MS returns to the old cell and attempts to 
resume packet data transmission (see sub-clause 
8.10.5). 


1 s 


T3218 
(per 
MS) 


On receipt of PS HANDOVER COMMAND 
message or Handover from UTRAN Command 
message. 


Upon detecting of the first USF for any uplink TBF 
assigned to the MS in the new cell. 


The MS returns to the old cell and attempts to 
resume packet data transmission (see sub-clause 
8.10.5). 


1 s 


T3220 


When the PACKET PAGING REQUEST 
message containing MBMS pre-notification 
parameters, for an MBMS session the mobile 
station is required to receive, is received. 


Upon receipt of the PACKET PAGING REQUEST 
message containing MBMS notification parameters 
of the same session that started this timer or any 
other procedure on PCCCH not related to MBMS is 
triggered or a notification is received for a higher 
priority session. 


Mobile station in packet idle mode or MAC-ldle 
state: Return to DRX mode. 

Mobile station in broadcast/multicast receive 
mode: Remain in broadcast/multicast receive 
mode 


46 s 
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timer 


started 


stopped 


action at expiry 


value 


T3??? 


When the PACKET MBMS ANNOUNCEMENT 
message is received indicating an MBMS 
broadcast service or an MBMS multicast 
service to which the mobile station has 
subscribed and an MBMS session the mobile 
station has not received, and including the 
Restriction Timer or the Estimated Session 
Duration. 


When the mobile station enters packet idle mode, if 
the PACKET MBMS ANNOUNCEMENT message 
included the Estimated Session Duration. 

When the mobile station enters packet idle mode 
and completes the Transfer non-DRX mode period, 
if the PACKET MBMS ANNOUNCEMENT 
message included the Restriction Timer. 


The MBMS related information stored upon receipt 
of the corresponding PACKET MBMS 
ANNOUNCEMENT message is deleted. 


See sub-clause 
6.3.2.2 


T3290 

(per 

MSJD 

on an 

MBMS 

radio 

bearer) 


At reception of a downlink assignment (i.e. 
MBMS ASSIGNMENT, MBMS MSJD 
ASSIGNMENT) message assigning an MSJD 
to a mobile station receiving an MBMS radio 
bearer. 


Restarted on receipt of an RLC/MAC block 
including the corresponding MBMS Bearer Identity 
and the MSJD in the TFI field. 


The mobile station considers the MS_ID as 
released, i.e. it no longer answers when polled 
with the MSJD. 


5s 



T3158: 



T3162: 



T3164: 



T3166: 



T3168: 



T3170: 



Wait for sending measurement reports for network controlled cell reselection. 

This timer is used on the mobile station side to define the period for performing NC-measurements and send measurement reports in either packet idle or 
packet transfer mode in A/Gb mode and MAC-Idle or MAC-Shared state in lu mode (see 3GPP TS 45.008). 

Wait for Packet Uplink Assignment after reception of Packet Queuing Notification 

This timer is used on the mobile station side after received Packet Queuing Notification to define when to stop waiting for a Packet Uplink Assignment. 

Wait for Uplink State Flag After Assignment 

This timer is used on the mobile station side to define when to stop waiting for the USF determining the assigned portion of the uplink channel and repeat 
the procedure for random access. In multislot operation, it is enough that the assigned USF is noted on one of the uplink PDCHs. 

Wait for Packet Uplink ACK/NACK after sending of first data block 

This timer is used on the mobile station side to define when to stop waiting for a Packet Uplink ACK/NACK after sending of the first data block. 

Wait for PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or a MULTIPLE TBF 
TIMESLOT RECONFIGURE message 

This timer is used on the mobile station side to define when to stop waiting for a PACKET UPLINK ASSIGNMENT, MULTIPLE TBF UPLINK 
ASSIGNMENT, PACKET TIMESLOT RECONFIGURE or a MULTIPLE TBF TIMESLOT RECONFIGURE message after sending of a PACKET 
RESOURCE REQUEST message or a PACKET CONTROL ACKNOWLEDGEMENT message requesting new TBF. 

Wait for PACKET UPLINK ASSIGNMENT message after having done (M+1) Packet Channel Requests or after reception of a PACKET ACCESS 
REJECT message. 
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This timer is used on the mobile station side when having made M + 1 attempts to send a PACKET CHANNEL REQUEST or MPRACH PACKET 
CHANNEL REQUEST message or after reception of a PACKET ACCESS REJECT message. At expiry of timer T3 170, the mobile station shall abort the 
packet access procedure, indicate a random access failure to upper layer and perform autonomous cell re-selection according to 3GPP TS 43.022. 

The value of this timer is equal to the time taken by T+2S TDMA frames, T and S are defined in sub-clause 7.1.2.1.1. 

T3172: Prohibit packet access in the cell after PACKET ACCESS REJECT message has been received. 

This timer is used on the mobile station side on receipt of a PACKET ACCESS REJECT message corresponding to one of the mobile station's 3 last 
PACKET CHANNEL REQUEST messages. If T3172 expires before receiving an assignment message, the mobile station returns to packet idle mode or 
MAC-Idle state. 

After T3172 expiry packet Access is no longer prohibited in the cell but no Channel Request message shall be sent as a response to a page until a PAGING 
REQUEST message for the mobile station is received. 

T3174: Wait for successful packet access in new cell after Packet Cell Change Order. 

This timer is used on the mobile station side on receipt of a PACKET CELL CHANGE ORDER message. The timer is stopped upon successful completion 
of packet access in the new cell. On expiry, the mobile station returns to the old cell, performs cell update (or other GMM specific procedure) and sends 
PACKET CELL CHANGE FAILURE message. 

T3176: Stop handling of abnormal condition in the network controlled cell reselection procedure. 

This timer is started when T3174 expires or another abnormal condition occurs in the network controlled cell reselection procedure. The timer is stopped 
upon transmission of the PACKET CELL CHANGE FAILURE message. On expiry, the mobile station stops handling of abnormal condition in the 
network controlled cell reselection procedure. 

T3180: Wait for Uplink State Flag After Data Block 

This timer is used on the mobile station side to define when to stop waiting for the USF determining the assigned portion of the uplink channel after the 
previous RLC/MAC block is sent. In multislot operation, it is enough that the assigned USF is noted on one of the uplink PDCHs. If expired, the mobile 
station repeats the procedure for random access if there are no remaining TBFs. If it expires and there are one or more remaining TBFs the MS may 
reattempt the establishment of the corresponding uplink TBF. 

T3182: Wait for Acknowledgement 

This timer is used on the mobile station side to define when to stop waiting for temporary Packet Uplink Ack/Nack after the last RLC data block has been 
sent for the current send window or for the entire Temporary Block Flow. 

T3184: No Ack/Nack Received 

At exclusive allocation, this timer is used to detect a radio link failure condition. If expired, the mobile station performs an abnormal release with access 
retry. 

T3186: Supervision of the random access procedure 
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T3188: 
T3190: 

T3192: 

T3194: 

T3196 

T3200 

T3204: 



T3206 



T3208 



This timer is used on the mobile station side to define the maximum allowed time to repeat the sending of all PACKET CHANNEL REQUEST or 
MPRACH PACKET CHANNEL REQUEST messages. At expiry of timer T3186, the Packet Uphnk estabUshment procedure is aborted. 

This timer is used by a mobile station that supports multiple TBF procedures to define when to stop waiting for a MULTIPLE TBF UPLINK 
ASSIGNMENT message after sending a PACKET RESOURCE REQUEST message during a two-phase access that requests two or more uplink TBFs. 

Wait for Valid Downlink Data Received from the Network 

This timer is used on the mobile station side to stop waiting for the valid data from the network side either following the initial Packet Downlink 
Assignment/MBMS Assignment or after some previous downlink RLC data block. 

Wait for release of the TBF after reception of the final block 

This timer is used on the mobile station side when the mobile station has received all of the RLC data blocks. When timer T3192 expires the mobile station 
shall release the resources associated with the TBF (e.g. TFI) and begin to monitor its paging channel. 

Minimum time between stolen radio blocks for a given radio bearer. 

Following stealing a radio block for a given radio bearer, the mobile station shall expect to have this radio bearer scheduled via its USE within an interval 
defined by four times the duration of T3194, else link failure is reported to RRC. 

Wait for PACKET CS COMMAND message. 

This timer is used on the mobile station side to define when to stop waiting for the Packet CS COMMAND message. At expiry of timer T3196, the mobile 
station shall release all ongoing TBFs and start RR connection establishment as specified in 3GPP TS 44.018. 

RLC/MAC control message reassembly guard 

T3200 is used by the mobile station to control when it will discard segments of a partially received RLC/MAC control message. The mobile station shall 
have one instance of timer T3200 for each segmented RLC/MAC control message that the mobile station is capable of receiving in parallel. 

Wait for Packet Uplink Assignment after the first attempt to send a Packet Channel Request during a packet access procedure. The Packet Channel Request 
was attempted indicating 'Single block without TBF establishment' and the purpose of the packet access procedure is to send a PACKET PAUSE message. 

This timer is used by a mobile station with non-GSM capabilities to stop waiting for a PACKET UPLINK ASSIGNMENT message. At expiry of timer 
T3204, the Packet Pause procedure (sub-clause 7.6) is aborted. 

Wait for sending of the PACKET CELL CHANGE NOTIFICATION message after entering CCN mode 

This timer is used to control that the MS in CCN mode is not prevented to proceed with a cell re-selection for too long if it cannot send the PACKET 
CELL CHANGE NOTIFICATION message (e.g. T3192 is running and there is no uplink block granted to the MS). 

Maximum delay of the MS initiated cell re-selection after the point in time when the MS has sent the PACKET CELL CHANGE NOTIFICATION 
message in CCN mode. 

T3208 is used by the mobile station in CCN mode to decide when to stop waiting for network assistance for the cell reselection (see sub-clause 5.5. L la). 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 



415 



ETSI TS 144 060 V6.28.0 (2010-03) 



T3210 



T3214 



T3216 



T3218 



T3220 



T3222 



Wait for retransmitting the PACKET CELL CHANGE NOTIFICATION message after having sent the PACKET CELL CHANGE NOTIFICATION 

message for the first time (see sub-clause 5.5. L la). 

This timer is used to request the mobile station to retransmit the PACKET CELL CHANGE NOTIFICATION message in the case it has not received any 
PACKET NEIGHBOUR CELL DATA message nor PACKET CELL CHANGE CONTINUE message nor PACKET CELL CHANGE ORDER message 
nor the PS HANDOVER COMMAND message in response to the sending of the PACKET CELL CHANGE NOTIFICATION message sent for the first 
time. It can reduce the cell re-selection delay implied by entering CCN mode in case the first PACKET CELL CHANGE NOTIFICATION message was 
not received by the network. 

Wait for MBMS ASSIGNMENT message. 

This timer is used on the mobile station side to define when to stop waiting for the MBMS ASSIGNMENT message. At expiry of timer T3214, a mobile 
station in packet idle mode or MAC-Idle state shall return to DRX mode. A mobile station in broadcast/multicast receive mode shall remain in 
broadcast/multicast receive mode. 

Wait for the PACKET PHYSICAL INFORMATION message. 

This timer is used on the mobile station side to define when to stop waiting for the PACKET PHYSICAL INFORMATION message in the non- 
synchronized cell PS handover case (see sub-clause 8.10.4.4.4). At expiry of timer T3216, the mobile station shall abort the PS handover procedure, return 
to the old cell, send a PACKET CELL CHANGE FAILURE message using the first available uplink transmission opportunity (if PS handover from A/Gb 
mode was attempted) and attempt to continue all TBFs/RABs that were ongoing prior to the reception of the PS HANDOVER COMMAND 
message/Handover from UTRAN Command message (see sub-clause 8.10.5). 

Wait for the first USE for any uplink TBF assigned to the MS after receiving the PS HANDOVER COMMAND message or Handover from UTRAN 
Command message. 

This timer is used on the mobile station side to define when to stop waiting for a USE of any uplink TBF assigned to the MS in the new cell. 

At expiry of timer T3218, the mobile station shall abort the PS handover procedure, return to the old cell, send a PACKET CELL CHANGE FAILURE 
message using the first available uplink transmission opportunity (if PS handover hovaA/Gb mode was attempted) and attempt to continue all TBFs or 
RABs that were ongoing prior to the reception of the PS HANDOVER COMMAND message or Handover from UTRAN Command message (see sub- 
clause 8.10.5). 

Wait for PACKET PAGING REQUEST message. 

This timer is used to ensure that the mobile station stops waiting for a PACKET PAGING REQUEST message containing an MBMS notification part. At 
expiry of the T3220, the mobile station in packet idle mode or MAC-Idle state shall return to DRX mode unless it is already engaged in any other MBMS 
session and remaining in broadcast/multicast receive mode. 

An instance of the timer may be used during the notification of MBMS for mobile stations in packet transfer mode or in dual transfer mode. An instance of 
this timer may be started at the receipt of a PACKET MBMS ANNOUNCEMENT message when in packet transfer mode or in dual transfer mode. 

The instance of this timer is stopped either when the mobile station enters packet idle mode, if the PACKET MBMS ANNOUNCEMENT message 
included the Estimated Session Duration, or when the mobile station enters packet idle mode and completes the Transfer non-DRX mode period, if the 
PACKET MBMS ANNOUNCEMENT message included the Restriction Timer. 
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At expiry of an instance of this timer, the mobile station discards the MBMS related information stored upon receipt of the corresponding PACKET 
MBMS ANNOUNCEMENT message. 

T3290 Wait for Downlink Data identified with the assigned MS_ID during an MBMS radio bearer. 

This timer is used on the mobile station side to stop answering to polling during an MBMS radio bearer. 

T3290 has the same value as the one specified for T3190. 
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1 3.2 Timers on the network side 

For each timer, it is shown whether one timer instance is needed per MS, per TBF/MBMS radio bearer, per MS_ID or 
per RLC/MAC control message. 

Table 13.2.1 : Specification of timers used in GPRS on thie Network side 



timer 


started 


stopped 


action at expiry 


typical 
value 


T3169 


If counter N31 01 =N3101_MAX, 


None 


The network releases USF and 


5s 


(per TBF) 


or if counter N31 03 = 

N31 03_MAX an instance of 

T3169 is started for this TBF 




TFI resources. 




T3191 


When the last RLC data block is 


When the final PACKET 


The network releases TFI 


5s 


(per TBF) 


sent with the FBI bit set to '1 ' an 
instance of T3191 is started for 
this TBF 


DOWNLINK ACK/NACK or 
PACKET CONTROL 
ACKNOWLEDGEMENT is 
received 

Restarted at the transmission of 
an RLC data block with the FBI 
bit set to '1'. 


resource. 




(per 


When the PACKET TBF 


Restarted at the transmission of 


The network releases all the 




MBMS 


RELEASE message is sent 


a further PACKET TBF 


TFIs related to the MBMS radio 




radio 




RELEASE message 


bearer 




bearer) 










131 93 


When the final PACKET 


Stopped when the network 


The network releases TFI 


Greater 


(per TBF) 


DOWNLINK ACK/NACK or 


establishes a new downlink TBF 


resource 


than 




PACKET CONTROL 


using the same TFI value. 




T3192 




ACKNOWLEDGEMENT is 










received an instance of T3193 is 


Restarted at the reception of the 








started for this TBF 


final PACKET DOWNLINK 
ACK/NACK or PACKET 
CONTROL 
ACKNOWLEDGEMENT. 






T3195 


If counter N3105 = N3105_MAX 


None 


The network may reuse the TFI 


5s 


(per TBF) 


an instance of T3195 is started 
for this TBF 




resources. 




(per 


If counter N31 05 = 




The network may reuse the 




MS ID on 


N3105_MBMS_MAXan 




MS_ID on the corresponding 




an MBMS 


instance of T3195 is started 




MBMS radio bearer. 




radio 










bearer) 










T3197 


When PACKET CS RELEASE 


On receipt of PACKET SI 


The network shall send 


2s 




INDICATION message is 


STATUS or PACKET PSI 


CHANNEL RELEASE message 






transmitted. 


STATUS message indicating 
that the mobile station has 
received system information to 
maintain its radio resources 
after the release of the RR 
connection. 


(specified in 3GPP TS 44.018) 
to the mobile station. 




T3199 


If counter N3109 = N3109_MAX 


None 


The network releases the 


5s 


(per 


an instance of T3199 is started 




MSJD on the corresponding 




MS ID on 


for this MSJD. 




MBMS radio bearer. 




an MBMS 










radio 


At the point in time denoted by 








bearer) 


the Current MS ID Expiry Time 
while no PACKET CONTROL 
ACKNOWLEDGEMENT 
message has been received, an 
instance of T3199 is started for 
this MS ID. 
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T3169: 



T3191: 



T3193: 



Wait for Reuse of USF and TFI after the mobile station uplink assignment for this TBF is invalid 

This timer is used on the network side to define when the current uplink assignment for this TBF is 
surely invalid on the mobile station side so that the assigned USF(s) and TFI can be reused on the 
uplink. During that period the corresponding USF(s) is not broadcast. 

Its value is network dependent. The value of T3169 should be greater than T3180, T3182 and (for 
exclusive allocation) T3184. 

Wait for reuse of TFI after sending of the last RLC Data Block on this TBF. Wait for reuse of 
TFI(s) after sending the PACKET TBF RELEASE for an MBMS radio bearer. 

This timer is used on the network side to define when the current assignment for this TBF/MBMS 
is surely invalid on the mobile station side so that the TFI(s) can be reused. 

Its value is network dependent. 

Wait for reuse of TFI after reception of the final PACKET DOWNLINK ACK/NACK from the 
mobile station for this TBF. 



T3195: 



This timer is used on the network side to define when timer T3192 on the mobile station side has 
surely expired so that the TFI can be reused. 

Its value is network dependent. 

Wait for reuse of TFI when there is no response from the MS (radio failure or cell change) for this 
TBF/MBMS radio bearer. 



This timer is used on the network side to define when the current assignment for this TBF/MS_ID 
on an MBMS radio bearer is surely invalid on the mobile station side so that the TFI can be 
reused. 



T3197: 



T3199: 



Its value is network dependent. 

Wait for the indication from the mobile station that it has received needed system information 

messages. 

This timer is used on the network side to delay the release of RR connection release in order to 
maintain radio resources before the mobile station has indicated the receipt of system information 
messages specified in sub-clause 5.5.1.2 or 5.5.1.3. 

Wait for reuse of MS ID on an MBMS radio bearer. 



This timer is used on the network side to define for a given MBMS radio bearer when a(n) 
(re)assigned MS_ID is surely invalid on the mobile station side so that this MS_ID can be reused. 
During that period the corresponding MS_ID is not used. 

Its value is network dependent. 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 



419 



ETSI TS 144 060 V6.28.0 (2010-03) 



13.3 Counters on the Mobile Station side 



N3102 



N3104 



N3106 



At each cell reselection the mobile station shall set the counter N3102 to the value defined by the 
optional broadcast parameter PAN_MAX. Whenever the mobile station receives a Packet 
Ack/Nack that allows the advancement of V(S), the mobile station shall increment N3102 by the 
broadcast value PAN_INC, however N3102 shall never exceed the value PAN_MAX. Each time 
T3182 expires the mobile station shall decrement N3102 by the broadcast value PAN_DEC. When 
N3102 < is reached, the mobile station shall perform an abnormal release with cell re-selection. 

When the mobile station sends the first RLC/MAC block the counter N3104 shall be initialized to 
1. For each new RLC/MAC block the mobile station sends it shall increment N3104 by 1 until the 
first correct PACKET UPLINK ACK/NACK message is received. Then N3104 shall not be 
further incremented. If the N3104 counter is equal to N3104_MAX and no correct 
PACKET UPLINK ACK/NACK message has been received, the contention resolution fails and 
the mobile station behaves as specified in sub-clause 7.L2.3. 

N3104_MAX shall have the value: 

N3104_MAX = 3 * (BS_CV_MAX + 3)* number of uplink timeslots assigned. 

N3106 is used in lu mode on the mobile station side to detect link failures that may occur for a 
given uplink RLC entity and shall be reported to the RRC layer. It is incremented each time a 
response to a given request is not received before a specified response time. It is reset upon 
reception of a response within the response time requirements. If the counter N3 106 is equal to 
N3106max, a link failure has occurred that shall be reported to the RRC layer. There is one N3106 
instance per uplink RLC entity in TCH or DCCH TBF mode. 

N3106max shall have the value: 5. 



13.4 Counters on the Network side 



N3101: 



When the network after setting USE for a given TBE, receives a valid data block of this TEE from 
the mobile station in a block assigned for this USE, it will reset counter N310L If PS Handover is 
not ongoing, the network will increment counter N3101 for each USE for which no data is 
received for this TBE. N3101max shall be greater than 8. If N3101 = N3101max, the network shall 
stop the scheduling of RLC/MAC blocks from the mobile station for this USE and start timer 
T3169. 



N3103: 



N3105: 



During extended uplink TBE mode, counter N3101 shall not be incremented if the network does 
not require a mobile station to send PACKET UPLINK DUMMY CONTROL BLOCK messages 
when there is no other RLC/MAC block ready to send for this TBE in uplink radio blocks 
allocated by the network (see sub-clause 9.3.1b.2). 

The use of N3101 during PS Handover is implementation specific. 

N3103 is reset when transmitting the final PACKET UPLINK ACK/NACK message within a TBE 
(final ack indicator set to 1). If the network does not receive the PACKET CONTROL 
ACKNOWLEDGEMENT message in the scheduled block for this TBE, it shall increment counter 
N3103 and retransmit the PACKET UPLINK ACK/NACK message. If counter N3 103 exceeds its 
limit, the network shall start timer T3169. 

When the network after sending a RRBP field in the downlink RLC data block or in lu mode also 
RLC/MAC control block, receives a valid RLC/MAC control message from the mobile station, it 
will reset counter N3105. The network will increment counter N3105 for each allocated data block 
for which no RLC/MAC control message is received for this TBE. The value of N3105max is 
network dependent. 

During an MBMS data transfer, whenever the network receives a valid RLC/MAC control 
message from a mobile station identified by a given MS_ID value, it shall reset the counter N3105 
for that MS_ID. The network shall increment the counter N3105 for a given MS_ID for each radio 
block, allocated via the polling procedure to the mobile station identified by that MS_ID value, for 
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which no RLC/MAC control message is received. The value of N3105_MBMS_MAX is network 
dependent 

N3107 N3107 is used in lu mode on the network side to detect link failures that may occur for a given 

RLC entity and that shall be reported to the RRC layer. It is incremented each time a response to a 
given request is not received before a specified response time. It is reset upon reception of a 
response within the response time requirements. If the counter N3107 is equal to N3107max, a link 
failure has occurred that shall be reported to the RRC layer. There is one N3107 instance per 
downlink RLC entity in TCH or DCCH TBF mode. The value of N3 107max is network 
dependent. 

N3109: N3109 for a given MS_ID on an MBMS radio bearer is reset when transmitting for the first time 

the MBMS MS_ID ASSIGNMENT message including a polling request. If the network does not 
receive the PACKET CONTROL ACKNOWLEDGEMENT message in the scheduled block, it 
shall increment counter N3109 for that MS_ID and may retransmit the MBMS MS_ID 
ASSIGNMENT message. If counter N3109 = N3109_MAX, the network shall start timer T3199 
for that MS_ID. The value of N3109_MAX is network dependent. 
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Annex B (informative): 
RLC data block encoding 

B.1 Example 1 

Figure B.l provides an example of the use of the Length indicator in conjunction with the M and E bits. In the example, 
LLC PDU 1 continues from a previous RLC data block and ends in the RLC data block shown. LLC PDU 2 follows 
LLC PDU 1 and is completely contained within the RLC data block. LLC PDU 3 follows LLC PDU 2, beginning in the 
RLC data block shown, and continues into the next RLC data block. 



8 7 


Bit 
6 5 4 3 


2 


1 


Payload Type 


RRBP S/P 


USF 




PR 


TFI 


FBI 


BSN 


E = 


Length indicator = 1 1 


M = 1 


E = 


Lengtii indicator = 26 


M = ^ 


E = 1 


LLC PDU 1 (cont) 


LLC PDU 2 


LLC PDU 3 



MAC lieader 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 1 5 


Octet 1 6 


Octet 1 7 


Octet 41 


Octet 42 


Octet 43 


Octet N-1 


Octet N 



LLC PDU 1 



LLC PDU 2 



LLC PDU 3 



Figure B.l : Length indicator (LI) example 
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B.2 Example 2 



Figure B.2 provides an example of the use of the Length indicator when the end of an LLC PDU would fit within an 
RLC data block but the addition of the length indicator octet (to indicate the LLC PDU boundary) causes the LLC PDU 
to extend into another RLC data block. In the example, LLC PDU 1 continues from a previous RLC data block and has 
20 remaining octets. The first 19 octets are placed into RLC data block N, the Length Indicator is set to (to indicate 
that the LLC PDU does not end within the current RLC data block), and the 20* octet is placed in RLC data block N+1. 



RLC data block N 
bit 



8 7 


6 5 4 


3 


2 


1 


Payload Type 


RRBP S/P 




USF 




PR 


TFI 


FBI 


BSN 


E = 


Length indicator = 




1 M = 


E = 1 


LLC PDU 1 (cent) 



RLC data block N + 1 
6 5 4 3 



Payload Type RRBP S/P 


USF 1 


TFI 


FBI 


BSN 


E = 


Length indicator = 1 


1 M = 1 


E = 1 


LLC PDU 1 (cent) 


LLC PDU 2 



MAC header 
Octet 1 
Octet 2 
Octet 3 
Octet 4 



Octet 22 



MAC header 

Octet 1 

Octet 2 

Octet 3 (optional) 

Octet 4 



Octet 22 



LLC PDU 1 



LLC PDU 2 



Figure B.2: Length indicator (LI) example 



B.3 Example 3 



Figure B.3 provides an example of the use of the Length indicator when the end of an LLC PDU fits precisely into an 
RLC data block. In the example, LLC PDU 1 continues from a previous RLC data block and ends in the RLC data 
block shown. LLC PDU 2 follows LLC PDU 1 and fills precisely the RLC data block shown. 



Bit 

5 4 



Payload Type 


RRBP S/P 


USF 




PR 


TFI 


FBI 


BSN 


E = 


Length indicator = 7 


M = 1 


E = 


Length indicator = 1 1 


M = 


E = 1 


LLC PDU 1 (cent) 


LLC PDU 2 



MAC header 


Octet 1 


Octet 2 


Octet 3 


Octet 4 


Octet 5 


Octet 1 1 


Octet 1 2 



Octet 22 



LLC PDU 1 



LLC PDU 2 



Figure B.3: Length indicator (LI) example 
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B.4 Example 4 



Figure B.4 provides an example when the Length indicator is not used. As the example does not contain any LLC frame 
boundaries, no Length Indicator octets are needed. 20 octets is used for LLC data in each RLC data block. 

RLC data block N 
bit 
6 5 4 3 2 1 

MAC header 
Octet 1 
Octet 2 
Octet 3 

LLC PDU 1 



Payload Type 


RRBP S/P USF 1 


PR 


TFI 


FBI 


BSN 


E = 1 


LLC PDU 1 (cont) 



8 7 


RLC data block N + 
6 5 4 


3 


2 


1 


Payload Type 


RRBP S/P 




USF 




TFI 


FBI 


BSN 


E = 1 


LLC PDU 1 (cont) 



Octet 22 



MAC header 
Octet 1 
Octet 2 
Octet 3 



Octet 22 



LLC PDU 1 



Figure B.4: Example when Length indicator (LI) can be omitted 



B.5 Example 5 



Figure B.5 provides an example when the final LLC PDU (FBI=1) of a downlink TBF fills the RLC data block precisely 
in which case the Length indicator can be omitted. In the example, LLC PDU 1 continues from a previous RLC data 
block and ends in and fills precisely the RLC data block shown. 



Bit 



Payload Type 


RRBP S/P USF 1 


PR 


TFI 


FBI=1 


BSN 


E = 1 


LLC PDU 1 (cont) 



MAC header 
Octet 1 
Octet 2 
Octet 3 
Octet 4 



Octet 22 



LLC PDU 1 



Figure B.5: Example when Length indicator (LI) can be omitted 



B.6 Example 6 



Figure B.6 provides an example when the final LLC PDU (CV=0) of an uplink TBF fills the RLC data block precisely 
in which case the Length indicator can be omitted. In the example, LLC PDU 1 continues from a previous RLC data 
block and ends in and fills precisely the RLC data block shown. 
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Bit 



8 7 


6 5 4 3 


2 


1 


Payload Type 


Countdown value = 


SI 


R 


spare 


TFI 


Tl 


BSN 


E = 1 


LLC PDU 1 (cont) 



MAC header 
Octet 1 
Octet 2 
Octet 3 
Octet 4 



Octet 22 



LLC PDU 1 



Figure B.6: Example when Length indicator (LI) can be omitted 



B.7 Example 7 



Figure B.7 provides an example when the Length indicator can be omitted. As the LLC PDU 1 begins in the RLC data 
block N and continues to the next one, no Length octet is needed. 

RLC data block N 
Bit 

4 3 2 1 

MAC header 
Octet 1 
Octet 2 
Octet 3 
Octet 4 

LLC PDU 1 



8 7 


6 


5 4 


3 


2 


1 


Payload Type 




Countdown value 




SI 


R 


spare 


TFI 


Tl 


BSN 


E = 1 


LLC PDU 1 



RLC data block N+1 
Bit 



8 7 


6 5 4 


3 


2 


1 


Payload Type 


Countdown value 




1 SI 


R 


spare 


TFI 


Tl 


BSN 


E = 




Ll=10 




1 M=1 


E=1 


LLC PDU 1 (cont) 


LLC PDU 2 



Octet 22 



MAC header 
Octet 1 
Octet 2 
Octet 3 
Octet 4 



Octet 1 3 



Octet 22 



LLC PDU 2 



Figure B.7: Example when Length indicator (LI) can be omitted 
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B.8 RLC data block delimitation for EGPRS 
B.8.1 Example 1 

Figure B.8 shows the first 2 RLC blocks of a TBF (Down-link). Only the last segment of a LLC PDU requires a length 
indicator. 



r' RLC Block 

Bit 

5 4 



LLC PDU 



FBI=0 


E = 


Length indicator = 1 1 


E = 


Length indicator = 26 


E= 1 


LLC PDU 1 (cont) 


LLC PDU 2 


LLC PDU 3 



Octet 1 
Octet 2 
Octet 3 



Octet 13 
Octet 14 
Octet 15 



Octet 39 
Octet 40 
Octet 41 



Octet N2 



LLC PDU 1 

l" PDU of the 

TBF 


LLC PDU 2 


LLC PDU 3 



2™ RLC block of the TBF 
Bit 



8 


7 


6 5 4 3 


2 


1 




FBI=0 


E = 


Length indicator = 1 1 


E = 


Length indicator = 26 


E= 1 


LLC PDU 3 (cont) 


LLC PDU 4 


LLC PDU 5 



Octet 1 
Octet 2 
Octet 3 



Octet 13 
Octet 14 
Octet 15 



Octet 39 
Octet 40 
Octet 41 



Octet N2-1 
Octet N2 



LLC PDU 3 



LLC PDU 4 



LLC PDU 5 



Figure B.8: Example for the case when a LLC PDU stretches over more 
than 2 consecutive in sequence RLC data blocks (LLC PDU 3 and LLC PDU 5). 
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B.8.2 Example 2 



Figure B.9 shows the last 3 RLC blocks of a TBF consisting of N blocks (Downlink). When an LLC PDU fills an RLC 
data block precisely and adding an LI for it would push the LLC PDU into the next in sequence RLC data block, then 
the LLC PDU is present in this RLC data block without a corresponding length indicator. If this LLC PDU is not the 
last LLC PDU of the TBF, its delimitation is indicated by the first length indicator of the next in sequence RLC data 
block with value LI=0. In case when the LLC PDU, or the last segment of it, does not fill the RLC data block, a length 
indicator with value 127 is added as the last length indicator of the RLC data block. 



RLC Block with BSN=N-2 (mod SNS) 
Bit 



8 


7 6 5 4 3 


2 


1 




FBI=0 


E = 


Lengtii indicator = N2-13 


E = 1 


LLC PDU J+1 (continue) 


LLC PDU J+2 



Octet 1 


LLC PDU J+1 


Octet 2 




Octet 3 




Octet N2-1 1 




Octet N2- 10 






LLC PDU J+2 


Octet N2 





RLC Blocl<with BSN=N-1 (mod SNS) 
Bit 



8 


7 6 5 4 


3 


2 




1 




FBU 


=0 


E = 


Length indicator = 


E = 


Length indicator^ 7 


E=0 


Length indicator^ N2-1 1 


E=1 


LLC PDU J+3 


LLC PDU J+4 



Octet 1 
Octet 2 
Octet 3 
Octet 4 
Octet 5 



Octet 1 1 
Octet 1 2 



Octet N2 



LLC PDU J+3 



LLC PDU J+4 
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RLC Block with BSN=N (mod SNS) 

Bit 
7 6 5 4 3 2 1 



FBI=1 


E=0 


Lengtii indicator=6 


E=0 


Length indicator=12 


E=0 


Length indicator=127 


E=1 


LLC PDU J+5 


LLC PDU J+6 


Filling Octets 



Octet 1 
Octet 2 
Octet 3 
Octet 4 



Octet 5 


LLC PDU J+5 


Octet 1 




Octet 1 1 






LLC PDU J+6 


Octet 22 





Octet N2 

Figure B.9: Example for the case when the LLC PDU fills exactly the RLC data block 

(LLC PDU J+2 and LLC PDU J+4) and when the last LLC PDU cannot not fill 

the last RLC data block(LLC PDU J+6) 



B.8.3 Example 3 

Figure B.IO shows a TBF of one LLC PDU which fills exactly the RLC data block (Downlink). 



Bit 



8 


7 


6 


5 4 


3 


2 


1 












1 FBI=1 


E = 1 1 


LLC PDU 1 



Octet 1 
Octet 2 



Octet N2 



LLC PDU 1 



Figure B.10: Example for the case when a LLC PDU fills the RLC data block precisely. 
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Annex C (informative): 
Message Sequence Diagrams 

The following figures illustrate message sequences for: 

one phase mobile originated access (figure C.l); and 
network originated access (figure C.l). 



Start 131 86/T31 70* 

Stop 131 86/131 70, 
Start 131 62 



Mobile Station Network 

PACKET CHANNEL REQUEST 



StopT3170/T3162/T3186, 
Start T3 164 



Stop T3 164 
Start T3 166 



Stop T3 166 



PACKET QUEUING NQTIFICATIQN 



PACKET PQLLING 



PACKET CQNTRQL ACK * 



PACKET UPLINK ASSIGNMENT 



RLC/MAC block (USE) 



RLC/MAC data block (TLLI) 



PACKET UPLINK ACK/NACK (TLLI) 



Start N31 01 



StopN3101 



* Qptional 
Figure C.l : Message Sequence Diagram for one phase packet access 



Mobile Station 



Network 



Start T3 190 
Restart T3 190 



PACKET DQWNLINK ASSIGNMENT 



RLC/MAC data block (TFI) 



Figure C.2: TBF establishment initiated by the network 
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Annex D (informative): 
(void) 
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Annex E (informative): 
(void) 
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Annex F (informative): 

Examples of Countdown procedure operation 

This annex presents several examples of the countdown procedure operation. 
The following parameters are used in the following examples: 

TBC = total number of RLC data blocks that will be transmitted in the TBF; 

BSN' = absolute block sequence number of the RLC data block, with range from to (TBC - 1); 

NTS = number of timeslots assigned to the uplink TBF in the assignment message, with range 1 to i 



F.1 Example 1 



In this example, shown in the first column, the total number of RLC data blocks in the TBF (TBC) is 155, the number 
of timeslots (NTS) is 1, and BS_CV_MAX is 15. The second column shows the same example with BS_CV_MAX = 6. 



TBC 155 
NTS 1 
BS CV MAX 15 










BSN' 


CV 






137 


15 






138 


15 






139 


15 






140 


14 






141 


13 






142 


12 






143 


11 






144 


10 






145 


9 






146 


8 






147 


7 






148 


6 






149 


5 






150 


4 






151 


3 






152 


2 






153 


1 






154 








TBC 155 
NTS 1 
BS CV MAX 6 










BSN' 


CV 






137 


15 






138 


15 






139 


15 






140 


15 






141 


15 






142 


15 






143 


15 






144 


15 






145 


15 






146 


15 






147 


15 






148 


6 






149 


5 






150 


4 






151 


3 






152 


2 






153 


1 






154 








Figure F.I : Example 1 



F.2 Example 2 



In this example, shown in the first column, the total number of RLC data blocks in the TBF (TBC) is 155, the number 
of timeslots (NTS) is 3, and BS_CV_MAX is 6. Note that the RLC data block with BSN' = 154 arbitrarily occurs in 
timeslot 2. In the second column, the same example is shown with the RLC data block with BSN' = 154 occuring in 
timeslot 0. 

TBC 155 

NTS 3 

BS_CV_MAX 6 
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TSO 
BSN' CV 


TS1 
BSN' 


CV 


TS2 
BSN' 


CV 


125 15 


126 


15 


127 


15 


128 15 


129 


15 


130 


15 


131 15 


132 


15 


133 


15 


134 15 


135 


15 


136 


6 


137 6 


138 


6 


139 


5 


140 5 


141 


5 


142 


4 


143 4 


144 


4 


145 


3 


146 3 


147 


3 


148 


2 


149 2 


150 


2 


151 


1 


152 1 


153 


1 


154 






TSO 


TS1 


TS2 


BSN' CV 


BSN' CV 


BSN' CV 


127 


15 


128 


15 


129 


15 


130 


15 


131 


15 


132 


15 


133 


15 


134 


15 


135 


15 


136 


6 


137 


6 


138 


6 


139 


5 


140 


5 


141 


5 


142 


4 


143 


4 


144 


4 


145 


3 


146 


3 


147 


3 


148 


2 


149 


2 


150 


2 


151 


1 


152 


1 


153 


1 


154 














Figure F.2: Example 2 



F.3 Example 3 



In this example, the channel coding scheme is changed at BSN' = 149, resulting in more RLC data blocks being 
required to complete the TBF. The value of TEC is changed from 155 to 165 at BSN' = 149. 



TEC 



155 



NTS 3 

BS_CV_MAX 6 



TSO 


TS1 


TS2 1 


BSN' 


CV 


BSN' 


CV 


BSN' 


CV 


125 


15 


126 


15 


127 


15 


128 


15 


129 


15 


130 


15 


131 


15 


132 


15 


133 


15 


134 


15 


135 


15 


136 


6 


137 


6 


138 


6 


139 


5 


140 


5 


141 


5 


142 


4 


143 


4 


144 


4 


145 


3 


146 


3 


147 


3 


148 


2 


149 


5 


150 


5 


151 


5 


152 


4 


153 


4 


154 


4 


155 


3 


156 


3 


157 


3 


158 


2 


159 


2 


160 


2 


161 


1 


162 


1 


163 


1 


164 










Figure F.3: Example 3 
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Annex G (informative): 

Handling of erroneous protocol data, examples 

Procedures for the handling of erroneous protocol data are defined in sub-clause 11.1. These procedures define error 
labels for the treatment of syntactical errors in a received message. 

G.1 Application of error labels 

An RLC/MAC control message description could have an error label included, as shown in the examples below. 



< Packet XXX message content > ::= 

< FIELD_1 : bit (3) > 
<FIELD_2:bit(16)> 

< padding bits > 

! < Ignore : bit (*) = < no string > > 



In the case of a complete message, the contents of the received syntactically incorrect message can be ignored. 
Or 



< PRECEDING, 


FIELD 


bit (3) > 


{00 
101 
! < 


< FIELD 1 :bit(10)> 
<FIELD_2:bit(10)> 
Ignore : bit (2+10) = < no string > > } 


< FOLLOWING. 


_FIELD 


bit (8) > 



The syntactically incorrect description within the { } brackets can be ignored, the correctly received descriptions 
preceding and following the { } brackets shall be accepted. 

Or 



< Structure 1 struct > ::= 
<FIELD_1:bit(3)> 
{ 1 < FIELD_2 : bit (8) > } ** 

! < Ignore : bit (*) = < no string > > 



The above description indicates that the syntactically incorrect structure can be ignored. (Note: When this structure is 
included in the description of a message, any description following the structure must allow truncation.) 

G.2 Application of the 'Message escape' error label 

The 'Message escape' branch protects the comprehension of the description following bit '0', as shown in the example 
below. 



< Pacl<et YYY message content > ::= ~ Protocol version 1 
< FIELD_1 : bit (3) > 
{0 <FIELD_2:bit(16)> 

< padding bits > 
! < IVIessage escape : 1 bit (*) = <no string> > } ; 



The comprehension of 'FIELD_2' is required. If the receiver detects bit '1', the 'Message escape' branch is called and the 
remaining part of the message can be ignored. 
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The 'Message escape' branch may be used to introduce an new alternative coding of the message in a later version of the 
protocol. 



< Packet YYY message content > ::= ~ Protocol version 2 
< FIELD_1 : bit (3) > 
{0 <FIELD_2:bit(16)> 

< padding bits > 
I 1 -- New code option, replacing old 'Message escape': 

{00<FIELD_3:bit(12)> 

< padding bits > 
! < IVIessage escape : { 01 | 1 | 11 } bit (*) = <no string> > } } 



An alternative coding, including 'FIELD_3', is introduced following 'bit 1' in the former 'Message escape' branch. A 
new 'Message escape' is defined, this time using to control bits to allow future modification. 

A receiver implemented according to the original syntax will not accept the new coding. The original 'Message escape' 
branch will be called and the remaining part of the message, including 'FIELD_3' is ignored. The content of 'FIELD_r 
(e.g. information to identify the receiver) is accepted and can be used to determine appropriate condition handling. 

G.3 Application of truncated concatenation including 'padding 
bits' 

The truncated concatenation may include 'padding bits' at the end of a message. In that case, the resulting concatenation 
shall fit exactly with the received message length, otherwise the message is syntactically incorrect. 

The construction is useful, e.g. when a message ends with a sequence of optional components, where the transmitter 
may need to truncate tailing bits '0', indicating optional components not included in the message. 



< Pacl<et 777 


message content > ::= 


{" {0|1 
{0|1 


< Optional component 1 > } 

< Optional component 2 > } 


{ 1 1 < Optional component N > } 
< padding bits > } // ; 



If the optional components from k to N are not needed in the message, the transmitter may use the full message length 
for the components up to optional component k - 1. The receiver accepts this message and assumes that the choice bits 
for optional components from k to N are all set to zero (i.e. these components are not present). 

However, if the receiver detects a syntactical error within one optional component which is indicated as present in the 
message, that results in a truncated concatenation which does not fit with the received message length. In this case, the 
receiver shall not accept the message as being syntactically correct. 

An error label may be provided within a truncated concatenation to allow the receiver to accept part of a concatenation 
in case of a syntactical error within it. This is useful for recurring components at the end of a message. 



< Packet TTT message content > ::= 

{ { 1 { < Recurring component > ! < Ignore : bit (*) = < no string >>}}** 
< padding bits > } // ; 



If one of the recurring components is syntactically incorrect, the error branch is called. The error branch expands to the 
end of the message. The tail bit '0', terminating the recursion, and the 'spare padding' are truncated. The receiver accepts 
any syntactically correct instance of the recurring component preceding the syntactically incorrect one in the message. 
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G.4 Message extension using 'padding bits' 

The bit '0' in the first bit position of the 'padding bits', see sub-clause 11, may be altered into a bit '1' in future versions 
of the present document, in order to indicate an extension of the message content. When a message is received with bit 
'1' in this position, a receiver implemented according to the current version of the present document shall ignore the 
remaining part of the message. 

The example show how a message can be extended, relying on the fact that the 'padding bits' are defined with bit '0' in 
the first bit position. 



< Packet UUU message content > ::= -- Current version of the present document 

< contents defined in current version > 

< padding bits > ; 



The presence of the extension of the message content is indicated by bit '1'. The transmitter shall send a bit '1' in this 
position if any content is defined for the remaining part of the message. If a bit '0' is received in this position by a 
receiver in the new version, it shall ignore the remaining part of the message. 



< Pacl<et UUU message content > ::= -- Future version of the present document 
< contents defined in current version > 

{ null I bit** = < no string > -- Receiver backward compatible with earlier version 

I 1 -- Bit '1 ' sent by transmitter in new version 

< contents defined in a future version > 

< padding bits > } ; -- New 'padding bits' allows further extension 



G.5 IVIessage extension using the Extension Bits IE 

The Extension Bits IE defined in sub-clause 12.26 may be used in some messages or information elements as a place- 
holder for future extension when an extension at the end of the message is less suitable. The Extension Bits IE is usually 
included as an optional or conditional information element. When included, it provides a length indication and a 
corresponding set of 'spare bits', which may be used in future versions of the protocol to carry an extension of the 
message contents. 

When this extension mechanism is applied, the original Extension Bits IE shall be removed from the message and 
replaced by a new information element or a new construction, carrying an extension by up to 64 bits of the message 
contents. An example is given below. 



< Packet VVV message content > ::= 


- Current (original) 


version of the present document 


{ 1 1 < Extension Bits 


Extension Bits IE > } 


sub-clause 12.26 


< padding bits > ; 









The Extension Bits IE is replaced by a new construction named 'VVV Extension Info' . The new construction includes 
extensions introduced in Rel-M and Rel-N. In order to enable backward compatibility, truncation of the extension 
information may occur between released versions of the protocol. The receiver shall assume the value zero of any 
truncated bits. In order to enable forward compatibility, additional 'spare bits' may occur after the defined extensions. 
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< Packet VVV message content > ::= -- Future version of the present document; extensions in Rel-I\/I and Rel-N 

{ I 1 < VVV Extension lengtli : bit (6) > 

< bit (val{VVV Extension length) + 1) 

& { < VVV Extension Info > ! { bit" = <no string> }} > } 

< padding bits > ; 

< VVV Extension Info > ::= 

{ { -- Rel-M extension 

< Extension in Rel-M > } 

{ -- Rel-N extension 

< Extension in Rel-N > } 

< spare bit >** } // ; - Truncation may occur between released versions of the protocol 

- The receiver shall assume the value zero of any truncated bits 
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Annex H (informative): 
(void) 
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Annex I (informative): 
EGPRS RLC Window Sizes 



Although for each multislot allocation, the selected window size could preferably be the maximum, a smaller window 
size may be selected in order to optimize e.g. the number of (multislot) users and network memory consumption. 

However, for each MS, in order to meet a performance which corresponds to the number of timeslots allocated to this 
MS, the selected window size shall not be smaller than a minimum window size for this particular multislot allocation. 

For each network, the round-trip delay has a direct implication on the performance, hence on the defirution of the 
minimum window sizes. Consequently, no generic minimum window sizes are suggested. However, for information, 
the table below lists the window size ranges recommended with a round-trip delay of about 120 ms. 



Window size 


Coding 


Timeslots allocated 


(Multislot capability) 


1 


2 


3 


4 


5 


6 


7 


8 


64 


00000 


Min 
















96 


00001 




Min 














128 


00010 


















160 


00011 






Min 


Min 










192 


00100 


Max 
















224 


00101 










Min 








256 


00110 




Max 














288 


00111 


















320 


01000 












Min 






352 


01001 














Min 




384 


01010 






Max 












416 


01011 


















448 


01100 


















480 


01101 


















512 


01110 








Max 








Min 


544 


01111 


















576 


10000 


















608 


10001 


















640 


10010 










Max 








672 


10011 


















704 


10100 


















736 


10101 


















768 


10110 












Max 






800 


10111 


















832 


11000 


















864 


11001 


















896 


11010 














Max 




928 


11011 


















960 


11100 


















992 


11101 


















1024 


11110 
















Max 


Reserved 


11111 


X 


X 


X 


X 


X 


X 


X 


X 
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Annex J (informative): 

An example of iVICS-S retransmission 

This example shows the radio blocks of an MCS-8 RLC data block retransmitted using MCS-6 (padding) and MCS-3 
(padding). 

The following hypothesis are used: 

Uplink block; 

- The MCS-8 RLC data block contains three LLC PDU: last part of LLCl (last 40 octets), the whole LLC2 (length 
60 octets) and the first part of LLC3 (first 34 octets); 

No TLLI nor PFI is present. 



J.1 



Original MCS-8 RLC data block 

8 7 6 5 4 3 2 1 



TFI 


Countdown Value 


SI 


R 




BSN1 




TFI 




BSN2 




BSN 1 






BSN2 


Spare 1 PI 


RSB 


GPS 








Spare 








Tl 


E 




Length 


indicator = 40 




E 


LLC1 (octet 1) 


LLC1 (octet 2) 



LLCl (octet 39) 



LLCl (octet 40) 



LLC2 (octet 1) 



LLC2 (octet 2) 



LLC2 (octet 26) 



LLC2 (octet 27) 



Lengtii indicator = 33 



LLC2 (octet 28) 



LLC2 (octet 29) 



LLC2 (octet 59) 



LLC2 (octet 60) 



LLC3 (octet 1) 



LLC3 (octet 2) 



LLC3 (octet 33) 



LLCS (octet 34) 



Tl 



Octet 

1 (header) 

2 (header) 

3 (header) 

4 (header) 

5 (header) 
(See note 

below) 

1 (RLC data 1) 

2 (RLC data 1) 

3 (RLC data 1) 

40 (RLC data 1) 

41 (RLC data 1) 

42 (RLC data 1) 

43 (RLC data 1) 

67 (RLC data 1) 

68 (RLC data 1) 
(See note below) 

1 (RLC data 2) 

2 (RLC data 2) 

3 (RLC data 2) 

33 (RLC data 2) 

34 (RLC data 2) 

35 (RLC data 2) 

36 (RLC data 2) 

67 (RLC data 2) 

68 (RLC data 2) 



J.2 



NOTE:At this row, only a few bits are sent (not a full octet). 

Retransmission in two MCS-6 RLC data blocks 



When this RLC data block is repeated using MCS-6 (padding), the two radio blocks have the following format: 

Octet 

1 (header) 

2 (header) 



8 7 


6 5 4 3 


2 


1 


TFI 


Countdown value 


SI 


R 




BSNl 


TFI 
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CPS 




BSN 1 






Spare 


1 PI 1 RSB 


CPS 




Spare 


Padding 



3 (header) 

4 (header) 
(See note below) 

1 (RLC data) 



Padding 


1 Tl 


E 


Length indicator = 40 


E 


LLC1 (octet 1) 


LLC1 (octet 2) 



6 (RLC data) 
(See note below) 

7 (RLC data) 

8 (RLC data) 

9 (RLC data) 



LLC1 (octet 39) 



LLC1 (octet 40) 



LLC2 (octet 1) 



LLC2 (octet 2) 



46 (RLC data) 

47 (RLC data) 

48 (RLC data) 

49 (RLC data) 



LLC2 (octet 26) 



LLC2 (octet 27) 



73 (RLC data) 

74 (RLC data) 



8 7 


6 5 4 3 


2 


1 


TFI 


Countdown value 


SI 


R 




BSN 1 1 


TFI 




CPS 


1 BSN 1 








Spare PI 


RSB 


CPS 


Spare 


Padding 



Padding 


1 Tl 


E 


Length indicator = 33 


E 


LLC2 (octet 28) 


LLC2 (octet 29) 



Octet 

1 (header) 

2 (header) 

3 (header) 

4 (header) 
(See note below) 

1 (RLC data) 

6 (RLC data) 
(See note below) 

7 (RLC data) 

8 (RLC data) 

9 (RLC data) 



LLC2 (octet 59) 



LLC2 (octet 60) 



LLC3 (octet 1 ) 



LLC3 (octet 2) 



39 (RLC data) 

40 (RLC data) 

41 (RLC data) 

42 (RLC data) 



LLCS (octet 33) 



LLCS (octet 34) 



73 (RLC data) 

74 (RLC data) 



NOTE: At this row, only a few bits are sent (not a full octet). 
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J.3 



Retransmission in four IViCS-S RLC data blocks 



When the original RLC data block is repeated using MCS-3, the four radio blocks have the following format: 

Octet 

1 (header) 

2 (header) 

3 (header) 
(See note 1 below) 

1 (RLC data) 



8 7 


6 5 4 3 


2 1 


TFI Countdown value 


SI 1 R 


BSN 1 1 


TFI 


CPS 


BSN 1 


Spare 


PI RSB SPB 


CPS 


Padding 



Padding 


1 Tl 


E 


Length indicator = 40 


E 


LLC1 (octet 1) 


LLC1 (octet 2) 



6 (RLC data) 
(See note 1 below) 

7 (RLC data) 

8 (RLC data) 

9 (RLC data) 



LLC1 (octet 29) 



LLC1 (octet 30) 



8 7 


6 5 4 3 


2 1 


TFI Countdown value 


SI 1 R 


BSN 1 1 


TFI 


CPS 


BSN 1 


Spare 


PI RSB SPB 


CPS 




Tl 1 E 


LLC1 (octet 31) 


LLC1 (octet 32) 



36 (RLC data) 

37 (RLC data) 

Octet 

1 (header) 

2 (header) 

3 (header) 
(See note 1 below) 
(See note 2 below) 

1 (RLC data) 

2 (RLC data) 



LLC1 (octet 39) 



LLC1 (octet 40) 



LLC2 (octet 1) 



LLC2 (octet 2) 



LLC2 (octet 26) 



LLC2 (octet 27) 



9 (RLC data) 

10 (RLC data) 

1 1 (RLC data) 

12 (RLC data) 

36 (RLC data) 

37 (RLC data) 



8 7 


6 5 4 3 


2 1 


TFI Countdown value 


SI 1 R 


BSN 1 1 


TFI 


CPS 


BSN 1 


Spare 


PI RSB SPB 


CPS 


Padding 



Octet 

1 (header) 

2 (header) 

3 (header) 
(See note 1 below) 

1 (RLC data) 



Padding 


1 Tl 


E 


Length indicator = 33 


E 


LLC2 (octet 28) 


LLC2 (octet 29) 



6 (RLC data) 
(See note 1 below) 

7 (RLC data) 

8 (RLC data) 

9 (RLC data) 



LLC2 (octet 56) 



LLC2 (octet 57) 



8 7 


6 5 4 3 


2 1 


TFI Countdown value 


SI 1 R 


BSN 1 1 


TFI 


CPS 


BSN 1 


Spare 


PI RSB SPB 


CPS 




Tl 1 E 


LLC2 (octet 58) 


LLC2 (octet 59) 


LLC2 (octet 60) 


LLC3 (octet 1) 


LLC3 (octet 2) 



36 (RLC data) 

37 (RLC data) 

Octet 

1 (header) 

2 (header) 

3 (header) 
(See note 1 below) 
(See note 2 below) 

1 (RLC data) 

2 (RLC data) 

3 (RLC data) 

4 (RLC data) 

5 (RLC data) 



£75/ 



3GPP TS 44.060 version 6.28.0 Release 6 



443 



ETSI TS 144 060 V6.28.0 (2010-03) 



LLCS (octet 33) 



LLCS (octet 34) 



36 (RLC data) 

37 (RLC data) 



NOTE 1: At this row, only a few bits are sent (not a full octet). 
NOTE 2: In this radio block, the bits TI / E are meaningless. 
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Annex K (informative): 
Change History 



IVIeeting 
/Date 


Tdoc 


CR 


R 
ev 


Subject 


New 
Version 


GP-12 


- 


- 


- 


Generation of version 6.0.0 (Rel-6), based upon v5.4.0. 


6.0.0 


GP-12 


GP-022919 


242 


3 


Utilization of Pacl<et Uplinl< Dummy control block 


6.0.0 


GP-12 


GP-023257 


285 


1 


Clarification to the reallocation of uplink TBF in order to send 
upper layer PDUs at higher Radio Priority than the established 
TBF 


6.0.0 


GP-12 


GP-023367 


287 


2 


Clarification to the handling of T31 92 value set to 


6.0.0 


GP-12 


GP-023259 


288 


1 


Clarification of the presence of optional parameters in cell 
selection parameters broadcast on PBCCH 


6.0.0 


GP-13 


GP-030078 


293 




Requested access technology types for GSIVI900 in IVIultiple TBF 
Uplink Assignment message 


6.1.0 


GP-13 


GP-030080 


296 


1 


Undefined MS behaviour in case of undefined EGPRS IVICS 
values 


6.1.0 


GP-13 


GP-030087 


297 


1 


GPRS IVIobile Allocation, wrong character in "NF-1" 


6.1.0 


GP-13 


GP-030086 


298 


1 


Inconsistent definition of Cell_lndex_Start_RTD in PSI3ter 
message 


6.1.0 


GP-13 


GP-030082 


301 




CSN.1 coding of PSi3-bis 


6.1.0 


GP-13 


GP-030083 


304 




Inconsistency between CSN.1 and details of PACKET SI STATUS 


6.1.0 


GP-13 


GP-030085 


307 




Removal of CCN description from PSI3quater 


6.1.0 


GP-13 


GP-030079 


309 




Fixed Allocation Removal correction 


6.1.0 


GP-13 


GP-030081 


313 




Wrong Implementation CR 44.060 278r2 (GP-022931) 


6.1.0 


GP-13 


GP-030084 


315 




Removal of lu mode text from §9.1 .12b RLC/MAC Control 
IVIessage reassembly 


6.1.0 


GP-13 


GP-030310 


318 


1 


Wrong Length Indicator in TCH TBF mode 


6.1.0 


GP-13 


GP-030232 


320 




Correction to Packet Ack/Nack messages for SFACCH 


6.1.0 


GP-13 


GP-030313 


322 


1 


Correction to IVITBF Uplink Assignment message 


6.1.0 


GP-13 


GP-030314 


324 


1 


Wrong Implementation CR 44.060 263 rev 2 


6.1.0 


GP-13 


GP-030302 


330 


1 


Validity of the RBB and SSN in EGPRS RLC unacknowledged 
mode 


6.1.0 


GP-14 


GP-031060 


283 


4 


Clarification to GPRS cell reselection use in Packet IVIeasurement 
Order message. 


6.2.0 


GP-14 


GP-031028 


332 


4 


Enhancement of network controlled cell reselection procedure 


6.2.0 


GP-14 


GP-031038 


335 


3 


Indication of the IVIS support of "Modulation based multislot class" 


6.2.0 


GP-14 


GP-030629 


336 


1 


EGPRS Supplementary/Polling (ES/P) Field usage in RLC 
unacknowledged mode 


6.2.0 


GP-14 


GP-030633 


338 


1 


Conflicting implementations CRs 253r1 and 200r2 


6.2.0 


GP-14 


GP-030626 


340 




Correction to CBQ3 in PSI3 and PSI3bis 


6.2.0 


GP-14 


GP-030637 


342 


2 


Correction to wrong references to PACKET DL ACK/NACK 
message instead of EGPRS PACKET DL ACK/NACK message 


6.2.0 


GP-14 


GP-030695 


343 


1 


Missing SI15 option in PACKET SI STATUS message 


6.2.0 


GP-14 


GP-030635 


346 


1 


Clarification/correction of the usage of the PACKET PSI/SI 
STATUS message 


6.2.0 


GP-14 


GP-030614 


348 




MS reporting of radio-access capability in lu mod 


6.2.0 


GP-14 


GP-030927 


351 


1 


Shift between dynamic and extended dynamic allocation 


6.2.0 


GP-14 


GP-030717 


352 




Inclusion of the channel quality report in dependency of the ES/P 
field 


6.2.0 


GP-14 


GP-030932 


354 


1 


Correction to definition of T3168 in chapter 13 


6.2.0 


GP-14 


GP-030933 


357 


1 


Transmission of dummy blocks on FACCH, SACCH, SDCCH 


6.2.0 


GP-14 


GP-030935 


359 


1 


Missing MTBF messages in Downlink TBF release 


6.2.0 


GP-14 


GP-030800 


361 




Missing G-RNTI extension in Packet Control Acknowledgement 


6.2.0 


GP-14 


GP-030936 


363 


1 


Deletion of lu mode references 


6.2.0 


GP-14 


GP-031055 


365 


1 


Clarification for downlink power control when PR field is missing in 
RLC control blocks 


6.2.0 


GP-14 


GP-030833 


370 




Correction of capability to modify the BA(GPRS) list 


6.2.0 


GP-14 


GP-030871 


374 




Power control modes references removal 


6.2.0 


GP-14 


GP-031059 


375 


3 


Clarification of <GPRS REP PRIORITY> struct usage 


6.2.0 


- 


- 


- 


- 


Ref to (void) scis 11.1 .4.5 removed from 1 1 .1 .4.3. 


6.2.0 


GP-15 


GP-031162 


378 


3 


Correction of capability to modify the BA(GPRS) list 


6.3.0 
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Tdoc 


CR 
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ev 
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New 
Version 


GP-15 


GP-031163 


380 


1 


Correction of SI13Alt PBOCH Location parameter in lu mode only 
capable cells 


6.3.0 


GP-15 


GP-031165 


382 


1 


Correction of timeslot number allocation with power control 
parameters 


6.3.0 


GP-15 


GP-031167 


384 


1 


Correction to CSN.1 coding in EGPRS PACKET DOWNLINK 
ACK/NACK 


6.3.0 


GP-15 


GP-031663 


385 


2 


IVIapping of the PDTCH/D on PCCCH in case EGPRS 


6.3.0 


GP-15 


GP-031169 


389 




CSN.1 coding amendment to MULTIPLE TBF DOWNLINK 
ASSIGNMENT and MULTIPLE TBF UPLINK ASSIGNMENT 
messages 


6.3.0 


GP-15 


GP-031395 


395 




"Others" cells to report in PCCN 


6.3.0 


GP-15 


GP-031664 


396 


1 


Priority between PCCN and Packet Downlink Ack/Nack message 


6.3.0 


GP-15 


GP-031583 


405 


1 


Clarification of the Extended Dynamic Allocation 


6.3.0 


GP-15 


GP-031545 


411 




USF Allocation at DBPSCH Assignment 


6.3.0 


GP-16 


GP-032278 


376 


6 


Introduction of multiple TBFs into clause 7 for A/Gb mode 


6.4.0 


GP-16 


GP-032274 


392 


3 


Removal of the close-ended TBF feature 


6.4.0 


GP-16 


GP-032279 


393 


3 


Introduction of multiple TBFs into clause 1 1 for A/Gb mode 


6.4.0 


GP-16 


GP-031878 


394 


1 


Introduction of multiple TBFs into clause 12 for A/Gb mode 


6.4.0 


GP-16 


GP-032203 


400 


3 


Multiple TBFs Ch 1-6 


6.4.0 


GP-16 


GP-031963 


402 


1 


Alignment of T3174 and T3176 descriptions with new procedure 
text 


6.4.0 


GP-16 


GP-032196 


407 


3 


Improvements to Extended Dynamic Allocation for high multislot 
classes 


6.4.0 


GP-16 


GP-032287 


408 


3 


Introduction of limited 'Inter RAT NACC functionality 


6.4.0 


GP-16 


GP-032137 


414 


3 


Change of DTM core capability 


6.4.0 


GP-16 


GP-032294 


415 


2 


Priority of the Packet Downlink Ack/Nack Message 


6.4.0 


GP-16 


GP-032267 


419 


2 


Order of frequency bands in MS Radio Access Capability IE 


6.4.0 


GP-16 


GP-032261 


421 


1 


Enhanced measurement reporting encoding rules 


6.4.0 


GP-16 


GP-032145 


423 


1 


Missing timeslot number in downlink ack/nack messages 
(SBPSCH) 


6.4.0 


GP-16 


GP-032258 


424 


2 


Multiple TBFs Ch 8 


6.4.0 


GP-16 


GP-032207 


425 


1 


Multiple TBFs Ch 9 


6.4.0 


GP-16 


GP-032280 


426 


2 


Multiple TBFs Ch 13 


6.4.0 


GP-16 


GP-032084 


429 




Correction of the Power Reduction (PR) field encoding 


6.4.0 


GP-16 


GP-032210 


431 




Brackets in Packet Access Reject (also corrected by another CR) 


6.4.0 


GP-17 


GP-032564 


434 


2 


Combination of Extended Dynamic Allocation and 
USF GRANULARITY=4 


6.5.0 


GP-17 


GP-032804 


436 


3 


Correction to the MTBF abnormal release 


6.5.0 


GP-17 


GP-032656 


438 


2 


Correction of the handling PSI messages while in dual transfer 
mode 


6.5.0 


GP-17 


GP-032657 


441 




Establishment of downlink TBF after downlink TBF release, 
abnormal cases 


6.5.0 


GP-17 


GP-032658 


442 




Correction to (EGPRS) Packet Downlink Ack/Nack for multiple 
TBFs in A/Gb mode 


6.5.0 


GP-17 


GP-032659 


443 


1 


Network Indication of MTBF Support 


6.5.0 


GP-17 


GP-032507 


445 




Correction to recursive CSN.1 coding for multiple TBF 
uplink/downlink assignment messages 


6.5.0 


GP-17 


GP-032700 


446 


1 


Minor corrections to multiple TBF assignment message coding 


6.5.0 


GP-17 


GP-032685 


449 


1 


Correction to NC reporting before GSM Neighbour Cell List is 
acquired 


6.5.0 


GP-17 


GP-032797 


450 


1 


Addition of rules for handling PFC procedures in RLC/MAC in 
case PFI values are not excplicitly allocated for the MS 


6.5.0 


GP-17 


GP-032802 


451 


2 


MS behaviour on reception of assignment messages 


6.5.0 


GP-17 


GP-032563 


457 




Correction of faulty mirror CR 


6.5.0 


GP-17 


GP-032803 


458 


2 


Introduction of multiple TBFs into sub-clause 8 


6.5.0 


GP-17 


GP-032807 


459 


2 


Packet Ack/Nack messages for Flexible Layer One 


6.5.0 


GP-17 


GP-032809 


463 


2 


Clarification on CPS field setting for MCS-3 retransmissions of 

MCS-8 blocks 

(Implementation error undone in v6.6.0) 


6.5.0 


GP-17 


GP-032646 


467 




Use of RACH uplink / Uplink access burst block format for the 1 1 
bits EGPRS PACKET CHANNEL REQUEST on RACH 


6.5.0 


GP-18 


GP-040343 


454 


2 


Improved "Delayed Uplink TBF Release" 


6.6.0 


GP-18 


GP-040437 


466 


2 


Padding for MCS-8 retransmissions 


6.6.0 


GP-18 


GP-040103 


468 




Removal of incorrect text addition 


6.6.0 
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GP-18 


GP-040524 


470 


3 


PGGO with a 3G-target cell not supported by the mobile station 


6.6.0 


GP-18 


GP-040128 


471 


2 


RLG Buffer for MTBF in A/Gb mode 


6.6.0 


GP-18 


GP-040523 


482 


1 


Clarification on N3102 disabling 


6.6.0 


GP-18 


GP-040559 


490 


1 


Clarification on CPS field setting for l\/ICS-3 retransmissions of 
MCS-8 blocks 


6.6.0 


GP-19 


GP-040823 


491 




Clarification of USF-granularity in connection with Extended 
Dynamic Allocation 


6.7.0 


GP-19 


GP-040825 


493 




Correction to USF granularity assignment for multiple TBFs 


6.7.0 


GP-19 


GP-040861 


495 


2 


CSN.1 Coding optimization for USF assignment in case of MTBF 


6.7.0 


GP-19 


GP-040827 


497 




Correction of the size of response time fields 


6.7.0 


GP-19 


GP-041074 


504 


1 


Short access removal 


6.7.0 


GP-19 


GP-041155 


505 


3 


Applicability of individual NC parameters 


6.7.0 


GP-19 


GP-041089 


508 


1 


Rule for encoding SI1 in the set of PNCD messages 


6.7.0 


GP-19 


GP-041158 


511 


2 


Important correction to handling of PSCD messages 


6.7.0 


GP-19 


GP-041144 


512 


1 


Introduction of non-segmented provision of serving cell SYSTEIVl 
INFORMATION messages on PACCH 


6.7.0 


GP-19 


GP-041146 


513 


1 


Removal of Unsynchronized (blind) Cell Change Order towards a 
GSM cell 


6.7.0 


GP-19 


GP-040806 


514 




Removal of GPRS Extended Measurement reporting 


6.7.0 


GP-19 


GP-041147 


515 


1 


Removal of GPRS Idle Interference Measurements 


6.7.0 


GP-19 


GP-041136 


518 


1 


Correction to PSI5 message encoding due to erroneous CR 
implementation 


6.7.0 


GP-20 


GP-041298 


519 


2 


Introduction of extended RLC/MAC control message segmentation 


6.8.0 


GP-20 


GP-041616 


524 


1 


Correction of NACC behaviour when CI path loss criterion 
parameter becomes negative 


6.8.0 


GP-20 


GP-041688 


527 


1 


Behaviour of MS while in NACC operation and PCCO is received 
after change in radio conditions 


6.8.0 


GP-20 


GP-041726 


538 


2 


Clarification on sending SI and PSI STATUS messages 


6.8.0 


GP-20 


GP-041733 


542 


2 


Applicability of NC parameters, sub-clause 8.4.2 


6.8.0 


GP-20 


GP-041717 


543 


1 


Resource Reallocation for Uplink in Single TBF mode 


6.8.0 


GP-20 


GP-041600 


546 


1 


Two different definitions for "GPRS 3G MEASUREMENT 
PARAMETERS Description struct" 


6.8.0 


GP-20 


GP-041490 


549 




Action at expiry of T3192 


6.8.0 


GP-20 


GP-041604 


550 


1 


Error in CSN-1 encoding 


6.8.0 


GP-21 


GP-042277 


554 


2 


Correction of the MS behaviour in case of receipt of Frequency 
Parameters IE in a downlink assignment message while in DTM 
mode 


6.9.0 


GP-21 


GP-042109 


558 


1 


Correction of MS behaviour in case of receipt of a PACKET CELL 
CHANGE ORDER in DTM mode of operation 


6.9.0 


GP-21 


GP-042130 


564 


1 


Corrections to PSI1 4 content and applicability during Dual 
Transfer Mode and after the release of the CS connection 


6.9.0 


GP-21 


GP-042275 


566 


2 


Signalling support for CPICH RSCP based criterion for GERAN to 
UTRAN FDD cell reselection 


6.9.0 


GP-21 


GP-042280 


568 


2 


Addition of DTM enhancements 


6.9.0 


GP-21 


GP-042024 


569 




Correction for the GPRS RESELECT OFFSET default value 


6.9.0 


GP-21 


GP-042132 


570 


1 


Applicability of Uplink Control timeslot for multiple TBFs in A/Gb 
mode 


6.9.0 


GP-22 


GP-042579 


551 


4 


RLC data block usage during change of service demand 


6.10.0 


GP-22 


GP-042581 


575 


1 


MS behaviour on receiving PACKET CS RELEASE INDICATION 
message 


6.10.0 


GP-22 


GP-042763 


576 


3 


RLC protocol behaviour for MBMS data transfer 


6.10.0 


GP-22 


GP-042772 


578 


1 


Change to PS Timing Advance behaviour for DTM to Packet 
Transfer transition 


6.10.0 


GP-22 


GP-042705 


580 


1 


Addition of MBMS in GPRS Cell Options 


6.10.0 


GP-22 


GP-042895 


582 


2 


Addition of MBMS access procedures and MBMS SERVICE 
REQUEST message 


6.10.0 


GP-22 


GP-042894 


581 


2 


Addition of MBMS establishment procedure and MBMS 
ASSIGNMENT message 


6.10.0 


GP-22 


GP-042889 


587 


2 


Applicability of RESEGMENT bit during TBF using RLC 
Unacknowledged mode 


6.10.0 


GP-22 


GP-042585 


588 




Change to container length field in Packet CS Command Message 


6.10.0 


GP-22 


GP-042847 


592 


2 


Enhanced control of maximum output power in a common BCCH 
cell 


6.10.0 


GP-22 


GP-042773 


593 


1 


Support of extended RLCMAC control message segmentation 


6.10.0 
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GP-22 


GP-042645 


594 




Addition of PACKET CS REQUEST message in RLCIVIAC blocl< 
transmission priority list 


6.10.0 


GP-22 


GP-042856 


595 


1 


Enhancements to the UTRAN FDD neighbor cell reporting 


6.10.0 


GP-22 


GP-042692 


596 


1 


Impact of the "NO Frequency List" on serving cell parameters 


6.10.0 


GP-22 


GP-042689 


601 


1 


Condition of the presence of SI1 depending on the PSCD content 


6.10.0 


GP-22 


GP-042905 


574 


4 


Addition of the MNCI message 


6.10.0 


GP-23 


GP-050441 


584 


3 


Addition of MBMS address assignment procedure and IVIBMS 
MS ID ASSIGNMENT message 


6.11.0 


GP-23 


GP-050522 


591 


3 


Addition of release of an MBMS radio bearer 


6.11.0 


GP-23 


GP-050523 


603 


3 


RLC data block transfer during an MBMS radio bearer 


6.11.0 


GP-23 


GP-050131 


606 




Definition of broadcast/multicast receive mode 


6.11.0 


GP-23 


GP-050601 


607 


2 


Correction of MBMS messages 

(implementation editorially corrected in Table 1 1 .2.40.2) 


6.11.0 


GP-23 


GP-050571 


613 


1 


Editorial corrections 


6.11.0 


GP-23 


GP-050602 


615 


2 


Addition of MBMS Notification 


6.11.0 


GP-23 


GP-050333 


618 




Inconsistent CSN.1 coding in PDA message 


6.11.0 


GP-23 


GP-050419 


621 


1 


CSN.1 coding modification of PSi14 extensions 


6.11.0 


GP-23 


GP-050422 


624 


1 


Validity of the PNCD information 


6.11.0 


GP-23 


GP-050585 


626 


2 


Usage of the RANDOM_ACCESS_RETRY flag in Abnormal cell 
reselection 


6.11.0 


GP-23 


GP-050609 


627 


2 


Extended Dynamic Allocation: PACCH operation clarifications in 
case of Concurrent TBF 


6.11.0 


GP-23 


GP-050363 


628 




Uncoupling BSS paging coordination in GPRS NMO II / III and in 
DTM 


6.11.0 


GP-23 


GP-050365 


629 




PFI inclusion not allowed at TBF establishment if PFC not 
supported by the network 


6.11.0 


GP-23 


GP-050437 


630 


1 


Multiple TBF operation in extended uplink TBF mode 


6.11.0 


GP-23 


GP-050608 


632 


1 


Correction of the mobile behaviour at packet access failure 


6.11.0 


GP-23 


GP-050521 


633 




Introduction of GPRS Power Control Parameters IE 


6.11.0 


GP-23 


GP-050433 


634 




Correction to multiple TBF procedures after one phase access 


6.11.0 


GP-23 


GP-050525 


577 


3 


Introduction of MBMS Notification for MS in packet transfer mode 


6.11.0 


February 
2005 








MS Word comment removed, two table entries put in right order, 
indentation of comments in coding corrected, a couple of style 
corrections 


6.11.1 


GP-24 


GP-050839 


637 


1 


Correction to the rule of the SI1 presence depending on PSCD 


6.12.0 


GP-24 


GP-050847 


611 


3 


Addition of reconfiguration of an MBMS radio bearer 


6.12.0 


GP-24 


GP-050845 


644 


1 


Align naming to MBMS Session Identity 


6.12.0 


GP-24 


GP-050849 


641 




Editorial correction of MBMS ptm channel description IE 


6.12.0 


GP-24 


GP-050994 


651 




MBMS notification for MSs in dedicated mode 


6.12.0 


GP-24 


GP-050794 


638 




Description of T3220 


6.12.0 


GP-24 


GP-051135 


652 


1 


Clarification on mandatory support of Extended Dynamic Allocaion 


6.12.0 


GP-24 


GP-051132 


640 


4 


Extension of DTM to high multislot classes 


6.12.0 


GP-24 


GP-051127 


648 


2 
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